[00:35] <sophie-w> Today:
[00:35] <sophie-w> - Event local positions take 2: https://github.com/MirServer/mir/pull/2948
[00:35] <sophie-w> - Context switching back to CI & python
[06:34] <Saviq> <RAOF> "Specifically: there's an..." <- Looking at compositor support there, it's not very wide ;D
[06:34] <Saviq> AIUI fractional-scale is just hints, using viewporter under the hood anyway. Not sure how could clients do the trick without knowing the desired fractional scale ¯\_(ツ)_/¯ (Ref. [#2599](https://github.com/MirServer/mir/issues/2599))
[08:22] <RAOF> <Saviq> "Looking at compositor support..." <- > <@saviq:matrix.org> Looking at compositor support there, it's not very wide ;D
[08:22] <RAOF> > 
[08:22] <RAOF> > AIUI fractional-scale is just hints, using viewporter under the hood anyway. Not sure how could clients do the trick without knowing the desired fractional scale ¯\_(ツ)_/¯ (Ref. [#2599](https://github.com/MirServer/mir/issues/2599))
[08:22] <RAOF> Actually, even *using* the fractional scale protocol it's not entirely clear how clients would do the trick. Unless you assume that any client using `wp_viewporter` is rendering at the "correct" size and shouldn't get scaled by the compositor.
[08:23] <RAOF> (Although that makes the interaction with wl_surface.set_buffer_scale kinda weird?)
[08:24] <RAOF> Anyway...
[08:27] <RAOF> Today:
[08:27] <RAOF> - Renamed `DumbDisplayProvider` / `DumbFB` / `DumbBuffer` -> 'CPUAccessible*`, where not technically required ("dumb buffers" are visible in the KMS API)
[08:27] <RAOF> - Started fixing the probing issue on X11 by removing a `TODO` in the `DefaultDisplayBufferCompositorFactory` (so the `GLRenderingProvider` can to be selected on a per-output basis, which coincidentally gets us the necessary probing)
[08:27] <RAOF> - Resolved an ongoing SRU discussion
[08:27] <RAOF>  * Today:
[08:27] <RAOF> - Renamed `DumbDisplayProvider` / `DumbFB` / `DumbBuffer` -> `CPUAccessible\*\`, where not technically required ("dumb buffers" are visible in the KMS API)
[08:27] <RAOF> - Started fixing the probing issue on X11 by removing a `TODO` in the `DefaultDisplayBufferCompositorFactory` (so the `GLRenderingProvider` can to be selected on a per-output basis, which coincidentally gets us the necessary probing)
[08:27] <RAOF> - Resolved an ongoing SRU discussion
[08:27] <RAOF>  * Today:
[08:27] <RAOF> - Renamed `DumbDisplayProvider` / `DumbFB` / `DumbBuffer` -> `CPUAccessible*`, where not technically required ("dumb buffers" are visible in the KMS API)
[08:27] <RAOF> - Started fixing the probing issue on X11 by removing a `TODO` in the `DefaultDisplayBufferCompositorFactory` (so the `GLRenderingProvider` can to be selected on a per-output basis, which coincidentally gets us the necessary probing)
[08:27] <RAOF> - Resolved an ongoing SRU discussion
[08:28] <RAOF> Also, I see we have agenda items on the doc, so will show up to the next meeting (although I think we were due to show up Monday anyway?)
[08:28] <RAOF> EOW 🎉
[08:29] <Saviq> RAOF: Yeah, retro / demo / planning time (reminder: I'm off, but as agreed didn't want to throw you a Friday night meet)
[08:31] <RAOF>  * Today:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/c42af86ce444278fca38827f97cd454680e3cafb>)
[08:31] <RAOF>  * Today:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/c796e94331279d284feb66cf7572dd38d4da69a7>)
[09:22] <Saviq> Gah. How do I portably get from a /sys/devices/… path to a /dev/dri/… one 👿
[09:25] <RAOF> I think there's a device symlink somewhere in the tree?
[09:29]  * Saviq sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/13be7126aaf1d37dc11d5cd852f6ca959896752b
[09:30] <Saviq> `dev` has `<major>:<minor>`, but that doesn't exist here :P
[09:32] <RAOF> The dev file in that tree has major:minor? 'Cause you should be able to find the /dev/dri/card? from that.
[09:33] <Saviq> Yeah, but dev doesn't exist in a PCI tree here ;)
[09:33] <Saviq> So again, not portably…
[09:34] <Saviq> There's this:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/8667450f13ebc7e7e37ea680c008cd55291cb9f6>)
[09:34] <Saviq> But obviously not (easily) workable for Pi:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/807124b286e8703d1246cb29cf5e1f58af8adf0c>)
[09:35] <Saviq> But looks completely different on Pi:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/eb49f847dd392eed2dece1faafc3deb8e5de5ffb>)
[09:35] <Saviq> s///
[09:36] <Saviq> FWIW the device paths are:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/5fab5916c83870cc1dbe2a4aea54fbd2d81d3942>)
[09:38] <Saviq> I'll need to speak to udev probably
[09:40] <Saviq> Saviq: Except udev also isn't helpful 🤦‍♂️
[09:41] <alan_g[m]> I'm not sure why you want to do this: might there be another way to solve the motivating problem?
[09:41] <Saviq> On Pi, it does have DEVLINKS, which point at the by-paths path, but on i915, does not.
[09:41] <RAOF> There is a drm API for enumerating devices, but that's probably not helpful?
[09:43] <Saviq> alan_g[m]: Writing the checkbox tests, I get the `/sys` path per GPU, and wanted to run `drm_info` and `kmscube` per GPU. But those two take `/dev/dri` paths as arguments.
[09:45] <Saviq> Anyway, I'll manage, will start from /dev/dri rather than the other way around
[09:45] <Saviq> And can see now why it's a different tree - on i915 there can be multiple cards, in fact, as far as drm is concerned
[09:46] <Saviq> As you were. </rant>
[09:48] <RAOF> Saviq: Wat?
[09:48] <RAOF> * Wat?!
[09:49] <RAOF> Multiple cards per device in sysfs, or multiple devices in sysfs per /dev/dri/card?
[09:49] <Saviq> Per sysfs
[09:50] <RAOF> :blobcat_confused: 
[09:50] <Saviq> So there's a `…/drm/card0` here, and that's where the `dev` with `<major>:<minor>` lives
[09:51] <Saviq> Anyway. Udev's already done all that logic for me, and I can ask it for details by /dev/dri paths
[15:58] <sophie-w> Just a reminder that if miriway-unsnap gets too unwieldy my overengineered solution still exists https://github.com/wmww/snap-out
[16:00] <alan_g[m]> sophie-w: I know. I did try that, but it didn't work straight away (I forget why now) and fixing looked hard
[16:06] <sophie-w> shrug well, if you do run into any more issues feel free to report them. Other than the dependency issue I fixed a couple years ago I haven't seen any problems with it.
[16:09] <alan_g[m]> Like you said it was overengineered for what I needed (and didn't do what I wanted). Was quicker to write miriway-unsnap. (Feel free to propose an improvement)
[16:30] <Saviq> 🕡️ Today:
[16:30] <Saviq> - Looked into syncing JIRA ↔ GH, have something to apply in due time
[16:30] <Saviq> - Got drm-info and kmscube working in a checkbox provider reliably across platforms (x86, Pi)
[16:30] <Saviq> - Found a way to include X-requiring tools (`vdpauinfo`, `vkcube`…) in checkbox, will integrate those next
[16:41] <Saviq> 👋
[16:42] <alan_g[m]> Bye, have a good break!
[16:46] <alan_g[m]> Today:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/d3d35932fb42012300ba7ee75a12508b45d1286c>)