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]
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