08:39 Zeising: in mesa, there are 6 files in src/gallium/tools/trace that still use python2. What are these scripts used for? https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/gallium/tools/trace (for reference)
09:53 MrCooper: Zeising: they operate on traces generated by the Gallium trace layer
10:48 Zeising: MrCooper: Ok. So switching to python 3 (and breaking those scripts) should be OK? It sounds like they're used for debugging rather than part of the distribution, so to speak.
11:07 serkanvb: hi. I have a drm mode setting question. does a user-land program have to be drm-master in order to set drm modes? can a program run by a normal user (non-root) set DRM modes?
11:08 emersion: no, regular programs can't set DRM props
11:11 pq: serkanvb, DRM-master is required for anything that changes KMS state, including setting modes.
11:12 serkanvb: ok
11:13 pq: even if you got past the DRM-master requirement, you still would not be able to achieve anything by settings modes from a separate program directly
11:15 pq: serkanvb, xrandr only works, because it tells Xorg (the DRM-master) to change the mode. Then X11 delivers events telling everyone interested about the mode being changed. KMS does not have such events at all, no-one would know you changed the mode.
11:17 pq: well, apart from things starting to mysteriously fail when they were expected to succeed, which either leads to nothing working or the original DRM-master just overwriting your change
11:18 serkanvb: pq one thing bugging my mind about mode setting though. I looked at Ubuntu20.04 where wayland is used. gnome-shell is run by normal user. it can still mode-set that is change resolution thru libmutter. who is the DRM master in this case and how can gnome-shell can do this if it is not the master?
11:19 pq: serkanvb, gnome-shell (the program that uses libmutter) has DRM-master. It gets it from logind, which runs as root.
11:20 pq: Logind makes sure there is only one session on a seat active at the same time, and that active session is allowed to get DRM-master capable DRM fd from logind.
11:21 serkanvb: pq: ok. I thought any process who has DRM-master should also run as root. apparently this is not the case
11:21 pq: nope
11:21 pq: getting DRM-master requires root, but anyone like logind who gor DRM-master can give it to another process
11:21 pq: *got
11:22 pq: logind can also revoke DRM-master from the one it gave it to
11:22 serkanvb: pq: I have seen some sample libdrm code around. doing some mode setting etc. all these mean these code should be DRM-master to be able to do this things. https://waynewolf.github.io/2012/09/05/libdrm-samples/ for example
11:22 pq: yes, there are more than just one way of gaining DRM-master
11:23 pq: but never can you have two DRM-masters on the same device
11:23 pq: at the same time
11:23 serkanvb: pq: is it not like XGrabServer? I mean gaining DRM-master?
11:24 pq: yes and no, I guess depends on how you look at it. It's mutex, more or less.
11:24 serkanvb: one does RandR stuff between XGranServer and XUngrabserver. just a temporary state
11:24 pq: the main point is to allow KMS operations from at most one process at a time
11:24 serkanvb: right
11:25 pq: that's completely irrelevant, just an artifact of how X11 protocol works
11:25 serkanvb: interesting that I cannot see any thing related to being drm master in the example code above (not that you have to answer for some one else's code)
11:26 pq: serkanvb, a process that first opens a DRM device becomes DRM-master automatically. Not, if something already has opened the device.
11:27 pq: many simple test programs simply rely on that and being root
11:27 serkanvb: pq: you mean open("/dev/dri/card0", O_RDWR); for example. right?
11:27 serkanvb: this is what you mean by "opening the device"
11:28 pq: libdrm also has drmSetMaster() and drmDropMaster() funcs
11:28 pq: yes
11:29 serkanvb: pq: drmSetMaster should be called someone like logind as I understand. a process cannot just set itself master (if it does not belong to root especially)
11:29 pq: correct
11:29 pq: also cannot SetMaster if someone else is already master
11:30 pq: IIRC
11:30 serkanvb: ok. the usual mutex thingy
11:31 pq: serkanvb, if this is still about trying to change modes behind a display server's back, it won't work. If it works, it's a bug.
11:32 serkanvb: pq: of course it is :D
11:32 pq: xrandr works because it talks to the display server, not to DRM
11:32 serkanvb: pq: right. you made it clear.
11:34 serkanvb: pq: is it not a short coming that other display server(s) do(es) not have corresponding APIs. but again it is because that the event mechanism is not there to notify all the clients about mode setting the way XServer does thru XEvents. right?
11:36 pq: I'd say it's an intended shortcoming that there is no generic Wayland interface for configuring Wayland display servers (compositors).
11:38 pq: People who develop desktops did not want it. They already have their interfaces for configuration, and are not keen to implement a third.
11:38 pq: People also do not want random apps to mess up their desktops, like games on X11 do.
11:38 serkanvb: pq: 2 interface being one for x11 and 1 for wayland?
11:39 pq: X11 and a compositor-specific are the first two
11:39 pq: like GNOME has some D-Bus interfaces
11:40 serkanvb: pq: right. I recently realized that on Kubuntu 20.04 some kwindow app. revert whatever xrandr set to drivers preferred mode.
11:40 pq: yes, that's the fighting you get when you try to override a setting behind back
11:42 pq: serkanvb, I think "I want to set set a video mode" is really the wrong statement. It might better to sell it as "I want to support VM-viewer resizing." which is what you actually want to do, not to configure desktops.
11:43 pq: FYI, mutter has a pile of ugly heuristics to let your xrandr commands keep their effect while still supporting monitor hotplug
11:45 serkanvb: pq: I think VM-viewer business is a bit more complicated than what's going on real hardware. I mean required functionality wise. we want both host and guest to be able to set the mode (resolution) and other part to play along
11:46 serkanvb: pq: we have user cases for both full screen vm displays and windowed vm-viewers. both cases are legit
11:46 pq: indeed
11:46 pq: that's actually my point
11:47 pq: you can't make it work well with just "let's set a mode", it's more nuanced
11:47 serkanvb: pq: but then there is nothing wrong about my wanting to set guest resolution some random mode.
11:47 serkanvb: pq: I have realized that :D
11:48 pq: you can do that through your guest kernel virtual DRM driver
11:48 pq: the host should be in control of what modes the virtual driver reports to the guest OS
11:50 pq: serkanvb, like airlied said on #wayland, the host sets values in the virtual hardware, the virtual driver picks those up, and reports to guest OS
11:52 serkanvb: pq: yeah but we dot implement the driver but use whatever we have. in some cases (on wayland guests) the driver has a single mode for example. dont ask me why this is the case. in Xrandr case we add new modes and set them etc.
11:52 serkanvb: pq: the main problem is that we dont have the control over the whole pipeline (code wise)
11:53 pq: serkanvb, what do you mean? Is the VM-viewer not intimately tied to the VM implementation?
11:54 serkanvb: pq: and we want (whatever "we" means here) that we set a new mode whenever user drag resize the vm-window. so the modes virtual driver gives us are not enough
11:54 serkanvb: pq: we use vmgfx driver
11:55 serkanvb: pq: we cannot control the modes the virtual driver reports
11:55 pq: I suspect you have a misunderstanding somewhere. Maybe check with people familiar with vmwgfx.
11:56 serkanvb: pq: ok
12:16 serkanvb: pq: about the DRM-master thing. on a Ubuntu20.04 with gnome-shell I am able to open("/dev/dri/card0", O_RDWR). did I misunderstand you that this should not be possible? I mean when there is a DRM-master we should not be able open drm device.
12:18 pq: serkanvb, you may be able to open the device, but DRM-master is a separate concept. If you try to set something KMS, it will fail.
12:18 serkanvb: pq: ok
12:19 pq: a DRM device fd can have DRM-master or not, and it can change via drmSetMaster/drmDropMaster
12:20 pq: if you can open the device, you should be able to enumerate the KMS resources. You just can't change anything without DRM-master.
12:20 serkanvb: pq: right. read only stuff is ok. got it
12:21 danvet: pq, do I need to read the privacy screen thread or all going well?
12:22 pq: danvet, they might need assurance that adding KMS properties counts as new UAPI.
12:22 pq: danvet, look for your name in email from me, you'll see it.
12:23 danvet: "kms properties is new uapi"
12:25 danvet: hm disappointingly the docs aren't super clear on this
12:25 danvet: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#ioctl-support-on-device-nodes
12:25 danvet: this just says you should use properties, not private ioctls
12:25 danvet: I feel like this might need a patch to clarify ...
12:26 danvet: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation
12:26 danvet: "New cross-driver userspace interface extensions, like new IOCTL, new KMS properties, new files in sysfs or anything else that constitutes an API change ..."
12:27 danvet: pq, do you think we need to further clarify this in the docs?
12:27 danvet: "anything that userspace can notice is part of the uapi"
12:28 danvet: I mean linus has reverted stuff for reasons more or less matching https://xkcd.com/1172/
12:28 danvet: it gets a bit grey at the edges, but even stuff like w/a bits in the render engines that make shaders crash or not is uapi
12:34 pq: danvet, maybe it could use a TL;DR sentence somewhere. Having to find it under "testing" is not very discoverable.
12:34 pq: danvet, I'm been writing the device hot-unplug description btw.
12:34 danvet: maybe we should have a "what is considered uapi" section at the top
12:35 danvet: acked-by: linus
12:35 danvet: tldr; everything
12:35 danvet: pq, cool
12:36 pq: well... there is Linus' UAPI, and then there is intentional UAPI we have the rules for
12:37 pq: serkanvb, if you want DRM-master, you have to persuade the current DRM-master to give it up. But when it re-gains DRM-master again, it will likely assume that all KMS state is unknown and reset more or less everything to what it had. The video mode it will very likely reset even if nothing else.
12:40 serkanvb: pq: right. i got that it turns into some ugly rope tag game
12:55 nede: I'm trying to use X11 modesetting in combination with a Xilinx framebuffer driver which only supports AR24. In the DRM debug logging I see [drm:drm_atomic_check_only] [PLANE:28:plane-0] invalid pixel format XR24 little-endian. I tried to figure out why this is happening. fbdev is fine. With modesetting somehow a XR24 plane is beinig created, but I can't figure out why this is
12:59 imirkin: nede: it probably assumes XR24 support. if it's the base plane, XR24 == AR24, so you should just allow that
13:02 nede: ok, clear, then I have to solve it in the driver. Modetest also shows that AR24 is the only supported option
13:38 tango_: doesn't linus accept new uapi as long as it doesn't break the old one?
13:50 pinchartl: nede: which xilinx driver is that ?
13:51 pq: tango_, I suppose he does, but I have no idea how other sub-systems ensure their UAPI doesn't break or that the new UAPI makes sense before it is committed.
13:55 pinchartl: pq: most don't, and the only option is to cry later when we realize the uAPI is broken by design
13:56 tango_: I mean how would you know if the uapi was good enough until 5 years down the line anyway?
13:57 pinchartl: tango_: by at least trying to use it once ? :-)
13:57 pinchartl: there's no guarantee of course
13:58 tango_: linux doesn't have the X11 principle of “at least a use case before merging stuff in?”
13:58 pinchartl: the Linux kernel doesn't enforce that. DRM/KMS does
13:59 pinchartl: in theory the principle is supposed to be applied across the kernel, but just saying "I have a use case" without showing it is often enough in lots of subsystems
14:00 pinchartl: this is one of the cases where I hate Daniel Vetter for forcing me to do the thing I agree is right :-)
14:01 pinchartl: the best way to realize how many APIs are horribly broken is to start using them. I've painfully experienced that for the past year or so
14:15 ccr:eyes inotify/dnotify/fsnotify/whatevernotify
14:20 dolphin: airlied, danvet: any specific reason drm-intel-next-queued PR not applied yet?
14:20 dolphin: I was thinking about tagging the final one tomorrow, noticing the old one is still pending
15:58 danvet: hwentlan, forgot to cc you, but did you have a chance to look at may dma_fence annotation rfc with your DC pov?
15:58 danvet: I guess könig is thinking about this from the ttm side already
17:22 airlied: dolphin: mighta missed it last week, I'll pull it later today
17:22 dolphin: airlied: thanks
19:30 danvet: airlied, I think that pull got in 5 minutes after you sent out last week's one
19:30 danvet: or so
19:30 danvet: oh that was a different one I think
20:15 anholt:wonders how reasonable it would be to run container build scripts outside of gitlab-runner, for testing
21:33 anholt: heads up: updating the freedreno baremetal runner's gitlab-runner, since eric_engestrom has been seeing issues with a known bug in the runner breaking a cached container, and this should clear out the container cache but also catch us up to a whole bunch of bugfixes.
21:33 anholt: i'll try to restart your jobs if they get interrupted
21:34 eric_engestrom:is not sure if he's getting the blame or the credit here xD
21:35 anholt: thanks for incidentally prodding me to update so that hopefully our CI is more stable in other ways too?
21:37 eric_engestrom: sorry, then :P
21:50 karolherbst: oh now... we can't say st/mesa anymore, but have to say... frontend/mesa? :D
21:50 karolherbst: *no
21:51 kisak: inb4 fe/mesa or iron/mesa
21:54 kisak: iron:?
21:58 robclark: we can't say mesa/st ? why?
22:00 karolherbst: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/commit/d6287a94b697ffe12a4e576a38943cdf4e90cdb0
22:01 karolherbst: and more patches
22:01 karolherbst: so now we have src/gallium/frontends :)
22:01 karolherbst: ohh but we still have src/mesa/state_tracker
22:01 karolherbst: mhhhh
22:02 karolherbst: maybe st/mesa is the only valid exception :)
22:02 imirkin: sigh. why the pointless churn?
22:03 Kayden:not a fan either
22:03 imirkin: this is the problem with no-mailing-list reviews
22:04 imirkin: something like this gets snuck in without any real discussion
22:04 Kayden: there was discussion
22:04 Kayden: everybody NAK'd several earlier versions
22:04 imirkin: i didn't see it
22:04 Kayden: but I guess this one a bunch of people were OK with
22:04 Kayden: well, that's sort of the problem with reviews
22:05 imirkin: with gitlab-based reviews
22:05 Kayden: somebody always misses something
22:05 imirkin: with mailing lists, everyone always sees it
22:05 Kayden: I missed plenty of things on mailing lists too :)
22:05 imirkin: ok, then that's on you - mailing list is the equalizer
22:05 ccr: probably happens with any kind of review methodology, if there's enough (too much) to review.
22:37 xexaxo1: imirkin, karolherbst: speaking of merge requests, did you see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4993
22:38 xexaxo1: I wonder if it'll make sense for nouveau?
22:38 karolherbst: xexaxo1: let's say I've heard about it from other sources :p
22:38 xexaxo1:should dust off his nvidia cards
22:38 karolherbst: xexaxo1: doubtful. We only generate very small set of TGSI shaders ourselfes
22:38 karolherbst: mainly the blitter
22:39 karolherbst: and those are cached in memory
22:39 karolherbst: I think...
22:39 karolherbst: anyway, caching them in memory would probably be enough
22:40 xexaxo1: karolherbst: ack. did the bigger nouveau caching series land?
22:40 karolherbst: not yet
22:40 karolherbst: but yeah, that would help as well
22:40 karolherbst: just shaders with 15 opcodes at most aren't that expensive to compile anyway
22:41 xexaxo1: only 15 opcodes? give it some hitman shaders - pretty sure those are a little more taxing
22:41 karolherbst: xexaxo1: I meant the blitter
22:42 karolherbst: we don't use ttn yet though
22:42 karolherbst: because.. well.. there wouldn't be much of a benefit
22:44 xexaxo1: I'm getting old - could swear I saw some nouveau patches to use tgsi_to_nir()
22:45 karolherbst: well, there might be some. But I didn't saw those at least :p
22:50 mareko: how does intrinsic_store_output work with double? can it write dvec4 with writemask xyzw or does it split stores to xy and zw?
22:53 mareko: I guess the offset is in units of dvec2, or dvec4?
22:56 mareko: karolherbst: st/mesa will keep being st/mesa
23:00 mareko: it's still not too late to subscribe to gitlab
23:13 jekstrand: anholt: marge is broken
23:14 jekstrand: or whoever it is who set up marge
23:15 anholt: https://gitlab.freedesktop.org/marge-bot shows activity, I see a weird status 54 minutes ago though