00:10wlb: wayland Merge request !412 opened by Demi Marie Obenour (DemiMarie) Fix various miscellaneous undefined behaviors https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/412
09:23outfoxxed[m]: should xdg_positioner::set_offset's offset be flipped
09:23outfoxxed[m]: i would assume yes but kwin and mutter dont do that
09:27vyivel: outfoxxed[m]: no
09:27outfoxxed[m]: but it should be considered in the constraint that causes the flip?
09:27vyivel: …actually let me check again
09:28vyivel: "The offset position of the surface is the one used for constraint testing", yes
09:29outfoxxed[m]: but if constrained the offset shouldn't be considered in the constraint?
09:30vyivel: uhh okay i'm not sure anymore
09:31outfoxxed[m]: its not really specified but mutter kwin and wayfire dont apply it to flip
09:31outfoxxed[m]: wayfire seems to account for it in slide
09:34vyivel: okay afaiu the offset indeed isn't flipped
09:35vyivel: to apply flipping, anchor/gravity are inverted, then the new geometry is computed, and then offset is applied to it
09:35outfoxxed[m]: do you know what the offset is actually for? like what uses it
09:36outfoxxed[m]: vyivel: so offset is *NOT* used when calculating if the surface should flip or not?
09:37vyivel: offset is used to compute the resulting geometry, and if that geometry is constrained, constraint adjustments are applied
09:37outfoxxed[m]: including or excluding flip adjustment
09:38vyivel: including
09:38outfoxxed[m]: alright
09:38vyivel: (i'm mostly reasoning here based on wlroots code, which i believe to be correct but who knows)
09:38outfoxxed[m]: do you have an idea of anything that uses it
09:38outfoxxed[m]: to test what looks right
09:38vyivel: offset? idk
09:38vyivel: grep for it in gtk/qt maybe
09:38outfoxxed[m]: qt does not
09:38outfoxxed[m]: can check gtk
09:40outfoxxed[m]: nothing in the gnome gitlab for gtk either
09:41vyivel: gdk/wayland/gdkpopup-wayland.c:818
09:42outfoxxed[m]: thanks
09:51outfoxxed[m]: it looks like gtk doesn't use it in combination with flip
09:55kingwill101: Hi, i've been working on implementing a client library in dart. I've gotten to the point of wanting to figure using egl. problem is because i'm not wrapping libwayland-client there is no way i can just bind the egl.* calls. i'm wondering if there's documentation of fetching the relevant objects using the c api? Since i'd already have the ids used to create the relevant protocol objects.
10:08kennylevinsen: kingwill101: the tricky bit is that mesa needs to use the same display connection to have access to any objects, and mesa expects it as a struct wl_display (libwayland-client). Objects can’t be transferred to a different display.
10:10kennylevinsen: You can still do something without WSI by avoiding EGL and instead using GBM + GL + Wayland directly
10:12kennylevinsen: But otherwise you’d need either a patch to mesa to allow using a foreign wayland impl, or a protocol to allow mesa to borrow the objects it needs from a different display without owning the resources.
10:23kingwill101: Are there any resources on GBM ? Also i was wondering if it's possible to just create wl_proxy versions of the objects and pass them to c
10:29kennylevinsen: kingwill101: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_wayland.c?ref_type=heads#L2227 <- this is the egl implementation you’ll need to satisfy, might be good to study what you’re fighting
10:31kennylevinsen: GBM is a memory allocation API: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gbm/main/gbm.h?ref_type=heads
10:33kennylevinsen: For GBM + GL, looking at wlroots’ render and allocator code might be useful
10:40kingwill101: Thanks much, a bit above my head so gonna have to do some reading
12:09daniels: yeah, you are going to have to wrap libwayland-client, sorry
12:09daniels: either that or have your Dart implementation export a compatible C API that Mesa can use
12:09daniels: they need to share an in-order message queue
15:15kingwill101: daniels: mmh, to do that i figure i need to be able to tell the c api to use the same wayland objects that were previously created in dart? I'm not sure though if there's an api that does that. Initially i thought maybe to create serialized versions of the dart objects converted to wl_proxy but i'm not so sure
15:34kennylevinsen: That won’t share a display connection. Either you need to pretend to be libwayland and expose a libwayland-style C interface that mesa can use without needing to be taught new trick, or you need to use libwayland from dart for the wire portion. Alternatively you need to change mesa, or avoid WSI entirely as mentioned earlier.
15:35kennylevinsen: You need a single fd with an in-order message queue used by both mesa and your dart code.
17:09tarTLSeau: does https://wayland.freedesktop.org/toolkits.html not miss GNUstep?
17:15vyivel: fairly sure that page can be removed
17:24bluetail: Hello. Are there any problematic side-effects within the scope of Wayland implementations? Assume: KDE does its own stuff, it will only work within KDE. Is this possible given that one develops something for >Wayland< that it cannot run on anything except the target desktop environment?
17:43Company: bluetail: Wayland itself is just the messaging layer - what messages are sent is entirely up to the communicating parties
17:44Company: so yes, there can be messages that only KDE apps implement support for
17:49bluetail: is it a likely outcome that some commercial software will only run on KDE, and nowhere else?
17:49bluetail: In future
17:54Company: I would think that neither the commercial software, nor KDE, nor anyone else has an interest in achieving that
17:55Company: and it's not like you can't just implement those messages elsewhere, if you want to
17:58dottedmag: Haven't we seen some weird things like Zoom abusing KDE-specific extensions for screensharing, and also doing compositor sniffing to disable it everywhere else?
18:02Company: sniffing works independent of supported features though
18:04daniels: vyivel: I’d ack that MR
18:05daniels: dottedmag: Zoom just uses PipeWire afaik
18:05daniels: well, the portal
18:11bluetail: Company I've been thinking about Valve - if they choose one platform, could it happen that they implement sort of a Digital Rights Management service, in order to protect against illegitimate copies of software/games? And what about Netflix? Wouldn't they have interest in "protecting" ad absurdum?
18:23bluetail: * to only work on e.g KDE
18:23bluetail: Would other implementations of the wayland protocol get the chance to catch up?
18:24vyivel: yes, given that kde is foss
18:24vyivel: alternatively they can simply decide to ignore drm
18:25vyivel: (i also don't see how can they do anything about "illegitimate copies of software/games"…)
18:26bluetail: Well, on Windows some company install rootkits - which aren't even legal in many locations to start with
18:26bluetail: some companies*
18:26Company: vyivel: the game studios with Microsoft are trying to bring up a signed system, as anti-cheat protection
18:26Company: so this is DRM pushed by gamers
18:30vyivel: gamers really leaving no reasons to respect them huh
18:31bluetail: at the same time Rockstar Games allegedly published a cracked nodvd version of one of their games onto valve services
18:31bluetail: Had signature of Razor1911 according to news articles
18:31bluetail: I doubt Gamers want DRM
18:32bluetail: I mean... unless they believe in that it will eradicate cheaters, but d-uh
18:33bluetail: We already got DMA cheats...
18:33bluetail: whats next, reading out memory in real time? It already exists... But not commercially I think
18:33zamundaaa[m]: dottedmag: it did abuse a Gnome screenshot API for screen casting, yes. The newer pipewire thing is still guarded behind xdg current desktop being set to Gnome too...
22:41Company: bluetail: the cheaters do sell hardware mods these days and people are using them
22:41Company: there's recommendations for what motherboards work best for this stuff
22:59wlb: wayland Merge request !408 closed (Post better errors for invalid message sizes)
23:14nocoffei: goooooooood evening, party people! I have just spent the last ~4 hours hunting down a pretty ugly (and old) bug in Xorgs XKB module, and I believe I'm at the final boss.
23:15nocoffei: ofourdan whot: Lyude sent me. Do either of you have experience with the xkbcomp compiler? The bug has originated from there.
23:20nocoffei: (note: I care because this causes an irritating divergence in keyboard handling with Wayland-native versus Xwayland apps)
23:38kennylevinsen: that sounds like libxkbcommon-land
23:44nocoffei: it is specifically xkbcomp, which is not in libxkbcommon, but if there's someplace else I should be to ask about that, please point me in that direction