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
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
CodeSpelunker has quit [Ping timeout: 480 seconds]
lxsameer4 has quit [Ping timeout: 480 seconds]
creich_ has joined #wayland
creich has quit [Ping timeout: 480 seconds]
lockywolf has quit []
lockywolf has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
ppascher has quit [Ping timeout: 480 seconds]
lockywolf has quit []
lockywolf has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
ppascher has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
shankaru has joined #wayland
hergertme_ has joined #wayland
hergertme has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
naveenk2 has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
naveenk2 has quit []
juergbi has quit []
danvet has joined #wayland
juergbi has joined #wayland
naveenk2 has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
maxzor has joined #wayland
dcz_ has joined #wayland
jgrulich has quit [Remote host closed the connection]
hardening has joined #wayland
rv1sr has joined #wayland
Dami_Lu has quit [Read error: Connection reset by peer]
Dami_Lu has joined #wayland
MajorBiscuit has joined #wayland
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
ppascher has quit [Quit: Gateway shutdown]
duxsco has joined #wayland
jmdaemon has quit [Remote host closed the connection]
jmdaemon has joined #wayland
manuel1985 has joined #wayland
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #wayland
___nick___ has joined #wayland
manuel__ has joined #wayland
lxsameer4 has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
maxzor has quit [Remote host closed the connection]
jmdaemon has quit [Remote host closed the connection]
jmdaemon has joined #wayland
asocialblade has quit [Ping timeout: 480 seconds]
bodiccea has quit [Read error: Connection reset by peer]
ahartmetz has joined #wayland
bodiccea has joined #wayland
jgrulich has joined #wayland
shankaru has quit [Quit: Leaving.]
jmdaemon has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #wayland
TattooedTech has joined #wayland
devilhorns has joined #wayland
jgrulich has quit [Remote host closed the connection]
<kchibisov>
Is it correct that all xcursor configuration protocols were abandoned?
<emersion>
i think there was just one?
Company has joined #wayland
<kchibisov>
I guess.
<kchibisov>
Kind of sad, given that you can't really live reload cursor theme without dbus/inotify.
nerdopolis has joined #wayland
<davidre>
If it's important to you, you could propose a protocol
<davidre>
Lokking at the MR there was not that people where against it
<kchibisov>
I'm not entirely sure about chromium protocol. I think we'd end up with clients relying on it and not doing cursor theme loading at all.
<emersion>
in any case clients will need to have a fallback
<emersion>
for GNOME at least
caef^ has quit [Remote host closed the connection]
shankaru has quit [Quit: Leaving.]
<pq>
vsyrjala, emersion, re: KMS blob IDs; why are IDs aggressively re-used to begin with? Could the kernel stop doing that, like with PIDs?
<emersion>
yeah, that would be the simplest solution
<emersion>
not a full solution to the half-old half-new state
<pq>
then userspace just needs to deal with "no such blob ID" occasionally, relying on the next hotplug event to set things straight again
<pq>
true
rgallaispou has quit [Read error: Connection reset by peer]
<pq>
all blobs and other structs would need to embed a serial; that would be one solution of at least knowing when you have an inconsistent set of information
<pq>
or maybe KMS properties are simply not a good abstraction for values that the kernel can spontaneously change
<emersion>
alternatively, there could be a serial user-space can fetch via an IOCTL after fetching all of the state
<emersion>
if the serial returned there is newer than the one from the hotplug event, then user-space needs to ignore the uevent and wait for the next one
<emersion>
it's a bit more complicated to handle on user-space side
<pq>
that could work
<vsyrjala>
waiting for hotplug wouldn't be the right solution as long as the props can change outside f hotlug
<emersion>
how can they change outside of hotplug?
<vsyrjala>
it should just retry reading the state until it gets a consistent snapsnit
<vsyrjala>
by random stuff just replacing the prop
<emersion>
if the client is the master, they shouldn't?
<pq>
busy-loop blocking compositors?
<emersion>
or maybe some sysfs stuff can mutate the props?
<emersion>
that would be confusing without a hotplug event
<vsyrjala>
eg. getconnector can mutate the props.
<emersion>
right. but only the master can do a getconnector which changes the props
<emersion>
non-master getconnector will not force-probe (thanks to a patch by yours truly :P )
<emersion>
btw -- a getconnector which force-probes might trigger a hotplug uevent still?
<pq>
if a prop can change without a hotplug event or explicit request from DRM master, then DRM master would not know to fetch the prop when it changed, so it seems that design would be broken to begin with
<vsyrjala>
userspace has no real idea what can and can't change the props. and i don't think we can really guarantee that someone wouldn't just add some replace_blob() call in random places
<vsyrjala>
we should probably fix it so that the blob won't change unless the contents change
<emersion>
that would just be an optimization
<emersion>
if the driver does a random replace_blob() somewhere, without a hotplug uevent, i don't think user-space can behave sanely
<emersion>
same for any other prop really
<emersion>
pq, swick: how should we move forward with di? i think we should agree on ABI compat so that we can move forward with the low-level API and keep discussing in parallel about the high-level API
<pq>
emersion, well, yes. :-)
<emersion>
i'm a bit worried about getting stuck here
<pq>
I'm no shape to type up a tentative API for now.
<pq>
I also haven't read all your discussion there yet.
<emersion>
ok
<emersion>
let me know if i can do anything to move things forward then
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
I need to understand better what swick is thinking, because I can't really get it from the API draft.
<emersion>
i think pretty strongly that we should use an incremental approach
<emersion>
ie, one MR adds one single thing
<pq>
yeah, me too, more or less - the discussions are going far to far ahead on some aspect right now
<emersion>
MRs with many additions at once are hard to review because they are interleaved and trigger a lot of different threads
<pq>
that's why I've commented on only few things so far
<emersion>
yeah, swick's draft brings a lot of new abstractions at once, it's taken a while for me to digest it as well (got a bit confused along the way)
<daniels>
pq: I think serial is totally overkill and doesn't entirely solve the problem as long as state can change out of band; much better, as you say, to just use a cyclical rather than lowest-available idr
shankaru has joined #wayland
<pq>
daniels, and like emersion said, that doesn't ensure consistency without something like a serial.
<daniels>
you'd also need to modify the uevent to carry the serial
<emersion>
that's simple enough
<pq>
yes, like emersion suggested - and not embed serial into all blobs
<emersion>
we already have an optional connector ID and prop ID in there
<vsyrjala>
we have that connector->epoch_counter thing in the kernel. which is some kind of connector change serial. but making it sufficiently robust might involve some work
<emersion>
it'd be nicer to have a global serial
<emersion>
that way i don't have old info for one connector and new info for another connector
<emersion>
another workaround would be to debounce hotplug uevents by e.g. 150ms in user-space
<emersion>
not enough to be noticeable to end users, enough to mitigate races in most cases hopefully (finger crossing involved here)
<pq>
I'm not so sure about making the serial global... I'd more look in the direction of making the serial per-connector and requiring that a hotplug even that carries a serial must carry connector ID too. I.e. use per-connector hotplug events.
<pq>
*event
<emersion>
some uevents might affect multiple connectors
<emersion>
docks, DP MST…
<pq>
then you either have no serial (status quo), or you get an uevent for each
<emersion>
uevent for each would be a regression from my PoV
<emersion>
my compositor might trigger arbitrary commands when a set of connectors are connected
<emersion>
intermediate states may trigger unnecessary and undesirable actions
<pq>
the problem I see with a global serial is that changed on an unrelated connector may make you drop the correct information you fetched already
<emersion>
"oh you're running with 3 outputs, let's setup your workspace that way"
<emersion>
"oh now it's 2 outputs, let's change the layout and start this command because it looks like your home setup"
<pq>
ah, so docks and MST if how you would physically be able to connect/disconnect multiple connectors at the same time
rgallaispou has joined #wayland
<emersion>
"oh now only one output, looks like you're on the go, let's execute that other command and re-organize the workspaces once again"
<vsyrjala>
could we change the single connector id to a list in the uevent? or would that break userspace?
<emersion>
vsyrjala: we could use a different prop name to expose a list. but that would just be an optimization
<vsyrjala>
you seem opposed to optimizations :P
<emersion>
no connector ID means "potentially all connectors might have changed"
<emersion>
well, i think optimizations are fine, but they don't fix the root cause of the problem
<emersion>
pq, yeah, and IMHO that's better than having a half-old half-new state
<pq>
I see, and I can agree - re-fetching some connectors unnecessarily is less bad
tzimmermann_ has quit []
jgrulich has quit [Remote host closed the connection]
<daniels>
vsyrjala: just emit a different uevent
<emersion>
why would we need a different uevent?
<emersion>
a hotplug uevent without any prop means the whole KMS state needs to be reloaded
jgrulich has joined #wayland
<emersion>
adding new props to help userspace understand which part of the state changed is backwards-compatible
<daniels>
oh yeah, iswym
<daniels>
I'd misremembered how that event was structured
<pq>
It's not unusual that the enum string name has a fixed numerical mapping, and userspace can cut corners by not looking at the strings at all, but that's not quite the right thing to do. Some properties do not guarantee that.
<emersion>
swick: it just happens that the const value for "off" is 0, and for "on" it's 1
<emersion>
pq: all properties guarantee that…
<emersion>
the kernel never has an enum with entry definitions that change depending on the context
<swick>
but the enum is no uAPI so it could change at any time?
<pq>
the numerical value of an enum needs to be queried from the kernel at runtime, yes, that's the contract.
<emersion>
there's a dri-devel thread about this
<emersion>
from my PoV it's uAPI
<pq>
but in practise, userspace may not do that and can get away with it, so for some props it has become de-facto UABI
<swick>
if it's uAPI it should be in the headers
<pq>
it's not *that* kind of UAPI
<pq>
but it is UAPI in that if you change the values in the kernel, it will be a kernel regression
<pq>
the situation will be more interesting with enum properties, where not all drivers support all values for the enum - the reasonable way to tell that to userspace is to not enumerate those enum values that have not been implemented.
<emersion>
ofc i can't find back the thread :(
<emersion>
but i asked if there was a good use-case for forcing user-space to query the enum definitions
<emersion>
and there was none
<vsyrjala>
if i had a time machine i'd go back and make the kernel add a random offset to every value on each boot
<emersion>
;_;
<vsyrjala>
or maybe i'd just go back even further and not use strings as uabi in the first place
<jadahl>
swick: its uapi by accident, not deliberately
<emersion>
for libliftoff purposes having fixed values is important to me
<swick>
can we just create a new KMS
<jadahl>
about the same time as wayland2
<swick>
KMS is annoying me way more than wayland right now tbh
<jadahl>
when we can start fresh and make new mistakes and start longing for kms3 and wayland3
<vsyrjala>
emersion: why? remapping whatever your library uses to whatever the kernel uses should be easy enough
<emersion>
aren't we supposed to make less mistakes each time there is an iteration? :<
<jadahl>
emersion: not less, different
<swick>
less bad :P
<swick>
seriously though, depending on anything that's not clearly marked as uAPI is… not great
<emersion>
vsyrjala: libliftoff allows one to set a bunch of properties, but the user doesn't know which exact plane they're going to be applied to at that point
<emersion>
"i want this layer to have FB 42 and rotation 90"
<emersion>
then libliftoff does computations and test commits to pick a KMS plane
<jadahl>
it'd be obnoxious for drivers to have different int values for the same enum value for different planes...
<emersion>
then it sets the KMS props for that plane
<emersion>
yeah, it'd be obnoxious, and useless
<emersion>
so i decided not to care…
<vsyrjala>
i think requiring the same values for the same prop on same kind of object is reasonable
<emersion>
the biggest issue right now is that there's no good way to find out what the values are if you only have an object type and prop name
<emersion>
i think?
* emersion
reads the uapi again
<vsyrjala>
yeah, if different objects expose a different subset of the same prop i guess you'd have to go and query them all to get the full list
<emersion>
right, so you need a property ID, and these come from object IDs only
<emersion>
:q
<emersion>
err
<pq>
I think we went through this discussion a few years ago :-)
<emersion>
indeed
<emersion>
the cycle repeats :P
<pq>
use strings as enum values; that doesn't fit the lib API nicely...
<swick>
honestly stuff like this is annoying but KMS is just broken and fundamentally unusable in other ways
<pq>
swick, maybe, but that's no way to make friends in order to fix things.
<swick>
everything about actually presenting and timing things is either horrible or just nonexistent
<swick>
standardized properties do different things on different hardware
<vsyrjala>
those would be bugs
<swick>
the color pipeline can't really be exposed
<swick>
sure, the difference in behavior could be fixed and properties could be much better defined
<swick>
but, like, how much precision do you get at each point in the pipeline, where is dithering happening all of that just doesn't exist and can't really exist with KMS
<swick>
clipping or saturating? at each and every hardware block which is different for every piece of hardware
jgrulich has quit [Remote host closed the connection]
<vsyrjala>
i think we can just blame the hardware designers for all our woes ;)
<vsyrjala>
there are some proposals for describing the precision of the LUT/gamma stuff at least. i guess that idea could be extended to other hw blocks, but at some point we're definitely going to get into the "each hardware does this totally differently" territory
<swick>
V4L and libcamera got it right: a graph describing the hardware and some user space code to get a sensible API out of it
<vsyrjala>
there's nothing fundemental preventing describing the full pipeline for kms. apart from the difficulty in coming up with usable abstactions for some of the hw specifics
<swick>
sure, with arbitrarily complex properties and interactions between properties
<swick>
and then you'll have an older property which was implemented in different parts of the hardware which now overlaps slightly with a new property
<vsyrjala>
sure. but nothing about that is really specific to kms. same issues would be there no matter how you you transfer over the descriptors/state between userspace and kernel
<swick>
to me it's obvious that describing the hardware is a much easier problem than finding a single abstraction of hardware while exposing as much of it as possible
<swick>
and making bad abstraction in user space is much less horrible than in kernel uAPI
TattooedTech has quit [Quit: Leaving]
<vsyrjala>
you have to able to describe the hardware in abstract enough terms that you get a hardware agnositc uapi because no one wants to write hardware specific backends for every compositor
<vsyrjala>
also the uapi has to be simple enough that you have a non-zero chance if getting it to make the thing you want, rather than it always failing due to some magic bit you didn't even know about always being in the wrong stat
<swick>
vsyrjala: you don't need that code in every compositor, we have GL, Vulkan and now libcamera too. that's a concept that seems to work pretty well.
<emersion>
i don't see why the kernel vs. userspace lib is an issue
<emersion>
you get the same API design issues either way
<swick>
the difference is that changing the kernel API is really hard and on the user space side you can do whatever you want: provide different APIs, deprecate, start new, etc
<swick>
you can keep one API around while other clients start using a new one
<swick>
just imagine if OpenGL was a kernel level API
<i509VCB>
OpenGL would move at a glacial pace then lol
naveenk2 has quit []
rgallaispou has left #wayland [#wayland]
<emersion>
i see no difference
<emersion>
a kernel API can do all of that too
<zzag>
kchibisov: emersion: while looking at the chromium's cursor protocol, I wonder whether the cursor stuff should have been implemented similar to wl_buffer. In other words, create an abstract interface for cursor `wl_cursor` (it's already reserved but whatever), make wl_pointer.set_cursor take the cursor object, and define some wl_cursor factory protocols, e.g. one that creates a wl_cursor from wl_surface [...]
<zzag>
and one that takes a cursor shape and returns wl_cursor
<emersion>
i don't see what a separate wl_cursor object is buying us here
<zzag>
the idea was to unify cursor representation so you don't separate protocols/methods for pointer and tablet
<emersion>
ah, yeah
<emersion>
that ship has already sailed regardless
<emersion>
it would've been nice to have server-created wl_buffers for cursor images, unfortunately there's the case of animated cursors
<zzag>
what is it?
<zzag>
I believe that client can't communicate the timing via the wayland protocol
<emersion>
we could've had a factory interface which created a virtual wl_buffer containing a cursor image, from a cursor shape name
<zzag>
so cursor animations might be jerky if the client is slow?
<emersion>
then the client can attach it to a cursor surface to display it
<emersion>
but this doesn't work with animated cursors
<emersion>
well that's the case with any client animation really
<zzag>
emersion: well, it could. we would just need to store cursor images in an atlas and use wp_viewport to slide between sprites
<zzag>
not all compositors handle that nicely though
<emersion>
an atlas wouldn't really be necessary
<emersion>
you could have one wl_buffer per cursor image
manuel__ has quit [Ping timeout: 480 seconds]
<emersion>
and cycle between them
<emersion>
but it's not a nice API
<zzag>
yeah, specifying the cursor shape and letting the compositor figure out how to display the cursor would be easier, but as you mentioned above, it has its own issues
<kchibisov>
I kind of prefer client side rendering of cursor, so communicating theme name in its own protocol or as a part of some accessability protocol what I'd use.
<kchibisov>
Though, accessability stuff usually should be controlled in DE/compositor directly.
<jadahl>
why is cursor theme related to accessibility?
<kchibisov>
it's more of 'let's group common compositor user preferences into one protocol' rather than accessability..
Arnavion has quit [Ping timeout: 480 seconds]
<kchibisov>
Though, cursor could leave on its own, I won't like to have 10 protocols to control their exclusive option.
<kchibisov>
Yeah, so you'll have this via dbus and the other via wayland-protocol.
<kchibisov>
And sometimes when theme changes from dark to light cursor also changes.
jgrulich has joined #wayland
<kchibisov>
So the changes have a chance to not be atomically applied leaving new cursor with old theme for a frame.
<ManMower>
I've been seriously considering writing a patch to just remove animated cursor support from toytoolkit...
<jadahl>
maybe cursor themes should have dark vs light variants
<ManMower>
when someone figures out a way to test them in CI, we can add them back ;)
<kchibisov>
jadahl: they have.
<kchibisov>
At least default KDE thing (Breeze iirc).
<jadahl>
kchibisov: then it'd be "atomic" if one updates to the light/dark variant when the dark/light setting change
<jadahl>
ManMower: killing my favorite terminal emulator feature by feature, aren't you?
<kchibisov>
Or are you talking about different layout for cursor themes?
<jadahl>
(oops, should be a comma somewhere there)
<ManMower>
jadahl: until there's nothing left to bury!
<jadahl>
kchibisov: I meant as a response to the old theme for being there for a frame too many when things go from/to dark. that wouldn't be a problem if the cursor theme behaved like "normal" themes where they some how have a light vs dark variant
<ManMower>
though, I'll concede that a program that completely redraws its entire surface in response to a mouse click that causes no visible change is the kind of shining example code we should bundle with the wayland reference compositor. ;)
<emersion>
> I kind of prefer client side rendering of cursor
<emersion>
kchibisov: can you elaborate why?
<jadahl>
ManMower: i like my surfaces fully damaged thank you
<ManMower>
:D
<kchibisov>
emersion: do you really want to animate that spinning cursor inside compositor?
<kchibisov>
And how would you deal with custom cursors?
<emersion>
yes
<kchibisov>
custom animated cursors.
<ManMower>
h264 cursors
<jadahl>
kchibisov: fwiw, cursor "shape" vs client side cursor aren't in conflict
<emersion>
kchibisov: custom cursors go through the existing APIs
<jadahl>
you would still be able to switch between them in any way you want
<jadahl>
ManMower: pfft, h265 8k cursors
<jadahl>
so that my rpi can't play them
<jadahl>
:(
<kchibisov>
emersion: yeah, so we have 2 paths in each toolkit.
<kchibisov>
And some animated cursors are animated by toolkit, but the rest via compositor.
<ManMower>
jadahl: sounds good - if I can't ruin your terminal, I can at least obsolete your workstation
<jadahl>
my rpi is my workstation?
<ManMower>
;)
<jadahl>
maybe it should be
<jadahl>
need to install gcc on my libreelec
<ManMower>
when we're talking about "client side rendering of cursor" are we talking about just flattening it onto the client's canvas by some toolkit?
<ManMower>
because EFL actually did that for a hot minute, and it led to some entertaining discontinuity at the edges of windows
<jadahl>
ManMower: nah, just what we do now already with libwayland-cursor
<ManMower>
ah ok cool :)
<kchibisov>
Though, for simple clients not relying on anything, server side cursor is better.
<kchibisov>
If you purely rely on that protocol for rendering.
<jadahl>
wayland is a drawing api after all, or so some say
<ManMower>
:)
<kchibisov>
Yeah, text rendering should also be done in protocol so tts will be easy for clients.
<jadahl>
lets add input only windows so we can add one for each widget too
<jadahl>
sorry, surfaces
<kchibisov>
Amazing.
duxsco has quit [Quit: duxsco]
duxsco has joined #wayland
<kchibisov>
Could move keyboard repeat into compositor while at it.
<emersion>
compositors already handle cursors and keyboard repeat in general
<ManMower>
but I like spurious repeated keys under heavy system load. lets me know something's wasting CPU.
<emersion>
for compositor hotkeys
<kchibisov>
ManMower: exactly.
<jadahl>
ManMower: it's how you test if you're on wayland or x11. a light fork bomb and press a key
<ManMower>
haha
<kchibisov>
emersion: don't get me wrong, I'd like to have keyboard repeat inside compositor.
devilhorns has quit []
Major_Biscuit has quit [Ping timeout: 480 seconds]