ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
hardening has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
gryffus has joined #wayland
c7s has quit [Ping timeout: 480 seconds]
colordrops has quit [Quit: WeeChat 3.1]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
colordrops has joined #wayland
boistordu_ex has joined #wayland
boistordu_old has quit [Ping timeout: 480 seconds]
<wlb> weston Issue #579 opened by () The output destroy event is not handled correctly when the compositor exits https://gitlab.freedesktop.org/wayland/weston/-/issues/579
utf12 has quit []
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
tzimmermann has joined #wayland
dcz_ has joined #wayland
mvlad has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
benklop has quit [Read error: Connection reset by peer]
benklop has joined #wayland
ppascher has quit [Ping timeout: 480 seconds]
ppascher has joined #wayland
gryffus has quit [Read error: Connection reset by peer]
gryffus has joined #wayland
rgallaispou has joined #wayland
gryffus has quit [Read error: Connection reset by peer]
gryffus has joined #wayland
rgallaispou has left #wayland [#wayland]
rgallaispou has joined #wayland
rgallaispou has quit []
jmabr has joined #wayland
floof58 has quit [Read error: No route to host]
benklop_ has joined #wayland
benklop__ has joined #wayland
floof58 has joined #wayland
benklop has quit [Ping timeout: 480 seconds]
benklop_ has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #wayland
Major_Biscuit has quit []
MajorBiscuit has joined #wayland
gryffus has quit []
<emersion> > Colord cannot be a mandatory Wayland CM&HDR requirement in general
<emersion> agree. wlroots has no plans for colord integration
<dottedmag> Mandatory libraries in protocol? That's something new.
<emersion> that's not unheard of, e.g. wl_keyboard more or less requires libxkbcommon atm
<dottedmag> On the client side, right? Is there any complication for a compositor to not use libxkbcommon (setting aside how compositor itself reacts to the keyboard). Could it synthesize a keymap and send it to clients?
<jadahl> colord shouldn't be a mandatory component indeed
rasterman has joined #wayland
<jadahl> and for anyone who wants to use it, the compositor must do a lot, e.g. provide it with color devices (monitors), color profiles that colord didn't detect itself (anything in ~/)
<emersion> it could choose not to send any keymap
<emersion> then it's up to clients to use libxkbcommon, or not use it
<dottedmag> That would be a very poor compositor indeed. I'm thinking about a compositor that plays nicely with existing clients.
<emersion> such a compositor would need libxkbcommon to compile the keymaps i assume
<emersion> or maybe sending a fixed string as keymap is enough? not sure
<dottedmag> OK, so the issue is producing compiled xkm format? Okay, this sounds doable without libxkbcommon.
<emersion> the keymap send over waylanbd isn't in xkm
<emersion> it's in the text format
<emersion> but i'm not sure what it needs to contain
<dottedmag> Ah, even better. I didn't get to this part of protocol yet :)
<emersion> ie, i'm not sure a single-line "include en keymap" statement is enough
<kennylevinsen> "libxkbcommon compatible" indeed doesn't say a lot (keymap_format description of xkb_v1)
<dottedmag> I'd expect a compositor to send a full keymap (taken from somewhere -- not necessarily composed out of xkeyboard-config), so that the clients don't have to look it up.
pnowack has joined #wayland
<Levans> In line with libxkbcommon dependency, are the values sent in wl_keyboard.modifiers in a specified format, or is it an other hard dependency on the lib?
<SardemFF7> I’d assume any value sent is corresponding to the keymap, even in libxkbcommon case
<emersion> hm so not clear what the values would be in the "no_keymap" case then?
<dottedmag> I'd expect that no .modifiers event is sent if there is no keymap.
<SardemFF7> are there even modifiers in the no_keymap case?
<emersion> right, the compositor wouldn't even know how to recognize one…
<pq> if you have no keymap, then you have no definition at all about what key codes might mean, so
<pq> IOW, with no_keymap, all programs must magically agree on what the codes mean.
<SardemFF7> well, these codes are whatever the platform drivers give, right? so you still have #defines in evdev-something.h and you can always handle them via some gigantic binding list users have to fill when first launching the app :-D
<pq> you are assuming the key codes come from drivers...
<pq> they could come from... RDP
<SardemFF7> in the first case yeah, in the second you’d just have a binding table so e.g. you can make game that uses the keyboard better than these annoying hard-coded QWERTY games
<pq> so, no_keymap really means that someone has invented some other way to know how to figure out the meanings
<pq> and that standard Wayland protocol offers to way to figure out what that is
<pq> ISTR some IVI systems use some custom button codes, and clients "just know" what they mean.
floof58_ has joined #wayland
floof58 has quit []
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
c7s has joined #wayland
fmuellner has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.3]
MajorBiscuit has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.3]
MajorBiscuit has joined #wayland
pixeldud has joined #wayland
pixeldud has left #wayland [#wayland]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
<daniels> most of that weird IVI input doesn't even come through Wayland, it's just events on the CAN/LIN bus
<daniels> the motivator for no_keymap was just to allow people to avoid the 'overhead' of XKB in hyper-constrained systems - I think STB/TV was one, and I forget the other
<daniels> as for requiring libxkbcommon ... you could come up with some other library which handled the same textual keymap format (derived from the original XKB textual format with a couple of minor additions)
<daniels> ttbomk there isn't anything else out there which gives you a flat portable description of a keymap in a rich enough format
jgrulich has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
MajorBiscuit has quit [Quit: WeeChat 3.3]
Narrat has joined #wayland
tzimmermann has quit [Quit: Leaving]
pnowack has joined #wayland
jgrulich has joined #wayland
maxzor has joined #wayland
maxzor_ has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<daniels> emersion: ooi, did you ever get any complaints about having removed eglQueryWaylandBufferWL?
<emersion> daniels: none so far afaik, but saying we don't officially support proprietary drivers probably helps
<emersion> also note that we emulate mesa's wl_drm
<emersion> ideally we'll be able to drop that soon
jgrulich has quit [Ping timeout: 480 seconds]
<daniels> yeah, hopefully :) thanks!
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
pnowack has quit [Quit: pnowack]
jmabr has quit [Quit: Leaving]
agd5f_ has quit []
agd5f has joined #wayland
Narrat has quit []
kenny has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner has joined #wayland
mvlad has quit [Quit: Leaving]
hardening_ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
danvet has quit [Ping timeout: 480 seconds]