ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
julio7359 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
d42 has quit [Read error: Connection reset by peer]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
chapatt has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
<chapatt>
Hopefully this is the right place for this question. I'm writing a wayland client, and I'm working on hidpi awareness. As I understand it, I need the scale events from the output(s) my surface is displayed on. Do I need to bind the outputs from the global registry, set up my listeners then, saving any scale info, and later correlate those pointers with the surface enter events?
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Guru_DE has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Guru_DE has quit [Ping timeout: 480 seconds]
<riteo>
chamlis: AFAIK, ideally you should use `wl_surface::preferred_buffer_scale` or, in case the global is too old, keep track of all the outputs the surface's on and set the scale according to the highest-scaled output
<chapatt>
riteo: Hmm, it seems wl_surface_listener doesn't have a member .preferred_buffer_scale. Is my library just out of date?
<chapatt>
for the other method, that's where I was unsure. How do I get the scale factors of outputs? From what I can tell, only via the events they emit. So I wonder if setting my output listener at the time of the surface enter event is soon enough to get the output scale event
<chapatt>
Or if I have to save the globals, and later correlate with the surface enter/leave events. But comparing pointers seems wrong
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
privacy has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
guru__ has quit [Ping timeout: 480 seconds]
<chapatt>
I see that's not available till wl_surface version 6 which my system does not have. I am still interested in the other method, then.
guru_ has joined #wayland
<Company>
you'll need to track all the outputs and their scales then
<Company>
and correlate them
feaneron has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
chapatt has quit [Ping timeout: 480 seconds]
chapatt has joined #wayland
chapatt has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
<ofourdan>
that's pretty much unavoidable I think, as soon as such protocols get added, people will use and rely on them.
<emersion>
some regular client wasusing the wlroots privileged output configuration protocol just to get a fractional scale of an output
<emersion>
s/was/is/ probably
<ofourdan>
actually, you don't even need any priviledge protocol for that, just comparing what what wl_output and xdg-output advertise suffice to guess the fractional scale factor.
sima has joined #wayland
sally is now known as Guest2280
sally has joined #wayland
Guest2280 has quit [Ping timeout: 480 seconds]
<jadahl>
MrCooper: that is indeed bound to happen, no doubt
<MrCooper>
I don't see the need for any change in course; Wayland now has growing unique functionality which serves as incentive for porting to proper Wayland idioms
<pq>
MrCooper, my impression is that we get continuously spit on because we reject "everything" (and for a good reason IMO, but complainers either don't see it, or they have very good technical reasons for not being able to do the right thing). I'm trying to find a compromise.
<MrCooper>
and it's just about to take over from X as the most used Linux display protocol
garnacho has joined #wayland
iomari891 has joined #wayland
<pq>
Is there really incentive to port to proper Wayland idioms? Is that even technically possible?
<pq>
Exactly because Wayland has grown so fast so much, we are going to be spit on more and more, up to levels that it poisons the whole community.
neniagh has quit []
<pq>
You've probably noticed that I'm utterly sick of trying to stop bad designs. I don't review protocol extension proposals anymore.
<Decker>
no - there's incentive to cut out functionality that is provided other places. If there's no way to do it a wayland idomatic way it just can't be done. that doesn't make the inability to do something a 'feature'.
<pq>
Often the Wayland idiomatic way cannot be implemented by toolkits alone. It requires fundamental design changes in the applications themselves, after toolkits have started to offer new API to allow it.
<pq>
OTOH, once toolkits offer a new API that matches Wayland design, they could make a new major version release that deletes the old toolkit API that did not map to Wayland. At that point, the toolkit naturally stops using the legacy compatibility extension as well. Upgrading to new major version of a toolkit would be point where an application would face the re-design.
<zzag>
pq: currently, making apps work good on wayland is the main incentive to adapt their apis to new idioms; with compatibility protocols, the clients will simply refuse to adopt wayland "native" idioms. that's disappointing, but that's the way things are. the clients are resistant to changes
soreau_ is now known as soreau
<pq>
zzag, can't the toolkit in between the app and Wayland do that instead, so that we could have old apps still work with old toolkits?
<zzag>
pq: toolkits are between the hard place and the rock
<zzag>
at least I can say that for Qt
<zzag>
Qt can't just change/break its APIs
<pq>
isn't that because you have promised to support an API that just cannot work on Wayland?
<zzag>
pq: yeah, kind of. but those apis are broken now anyway
<zzag>
for example, popup placement is still a challenge in Qt
<zzag>
there were some attempts to address that
neniagh has joined #wayland
<zzag>
but due to old code, lots of platform specific quirks and so on it has been proved to be far more harder than expected
<pq>
My idea is offering you a way to implement your existing APIs on Wayland and let them work, until we all have the Wayland idiomatic replacements designed and rolled out. The you can remove your old API in your next major release?
<pq>
I mean, I'm suggesting a PR stunt, essentially
<pq>
OTOH, I'm really delighted to hear opinions against legacy compatibility extensions. :-)
<pq>
please pour them in the Gitlab issue, so that we can show they have been considered at least
<pq>
rather than "upstream" looking like they deliberately want to break everyone's apps
<pq>
...for no good reason
<jadahl>
pq: I think adding traditional compatibility just removes any incentive to port to "proper" methods, and we'll have the exact same problem with Wayland 2.0 and the exact same work around will be needed. I realize the implications of that though.
<pq>
and please make those comments well justified and explained
<pq>
pulling the plug on Xwayland, then?
<jadahl>
what do you mean?
kts has quit [Ping timeout: 480 seconds]
<zzag>
pq: speaking for KDE, I'd rather personally abstain for now because we (KDE) have no shared consensus on this matter. one part of the camp is in favor, the other opposes
<pq>
Xwayland is purely a compatibility layer meant to let old apps work, and compositors have to do really unwaylandy things like letting X11 clients position their windows to make it work. Why would that deserve to live?
<pq>
zzag, okay.
<jadahl>
pq: Xwayland *really* is for backward compatibility, adding a compat namespace is backward compat in theory, but far from it in practice
<pq>
jadahl, I don't understand the difference.
<MrCooper>
one difference is that it's still just X, whereas Wayland "compatibility" protocols let clients pretend they've ported to Wayland
<pq>
right, and apps and toolkits already pretend that
<pq>
maybe that was the mistake
<jadahl>
pq: there is incentive to port to Wayland in a way that doesn't require introducing the rigid windowing sytsem methologies, even if it takes some effort. if you add a "compatibility" protocol layer, you completely remove the incentive to adapt to the non-rigid windowing system methologies
<pq>
ok
<pq>
(It's not me you need to convince.)
<pq>
that's why should put your opinions in gitlab
<jadahl>
pq: I just tried to explain the difference
<ifreund>
yeah, I'm starting to feel like we could shoot ourselves in the foot here and end up with nearly every toolkit using all the compat protocols we give them forever
<jadahl>
thats not really "opinions" of "nay" vs "yay", merely an observation of the likely outcome
<pq>
let me ask this: why did any toolkit ever jump on the Wayland bandwagon to begin with?
<pq>
why start on that horrible amount of work? There must have been extremely high pressure from something to make that happen.
<pq>
Where did that pressure disappear now?
<jadahl>
did it disappear?
<pq>
evereyone here seems very worried that toolkits stop making changes as soon as they can.
<pq>
so why did they choose to go to Wayland at all?
<zzag>
because it's a new flashy thing? :D
<selckin>
release of hidpi monitors
<pq>
I'm really curious myself, too, because even though I think I was here through that time, I have no recollection of the driving force.
<pq>
I would that the same force that got toolkits to move onto Wayland in the first place, would also be pushing them away from the legacy compatibility extensions as soon as they can.
<pq>
*I would think/hope
<jadahl>
pq: the "every frame is perfect" slogan perhaps
<jadahl>
or the "ability to lock the screen when a popup menu is open"
<pq>
Would legacy compatibility extensions really take those away?
<jadahl>
that depends on how far those protocols go in terms of backward compatibility
<davidre>
Maybe toolkit developers were as sick as compositor developers of having to deal with X :D
<pq>
right
<colinmarc>
rewrites are like catnip for engineers
<pq>
In hindsight, toolkits should have designed new APIs that match Wayland idioms well as the first thing, roll those out to applications and remove the old APIs, and then actually port to Wayland. But that means they should have been at the forefront of defining what Wayland is.
<ifreund>
wayland has always been developed primarily by compositor authors no?
<pq>
I think so, and that may have caused the problem.
<pq>
Seems like the above might have been krh's plan: build the plumbing, and then let the window management interfaces grow organically based on what DE people want.
<pq>
we know how that went with wl_shell as a MVP example, and how we then got xdg-shell
iomari891 has quit [Ping timeout: 480 seconds]
<pq>
I still remember some toolkit maintainers saying they won't look at Wayland until it's ready.
<ifreund>
heh, where "ready" is defined as feature parity with X perhaps?
<pq>
"you have a solution for everything that apps want to do" I suppose, yeah
<ofourdan>
pq: fwiw, that's what gtk4 does actually, redesing its api matching Wayland. As to why gtk3 was proted to Wayland at first, I reckon it is the same people (from intel and red hat) who were pushing for Wayland who contributed the Wayland backend in gtk at first.
<ofourdan>
*redesigning
<pq>
ofourdan, that's cool.
<ofourdan>
(well, that's my understanding at least, I might be wrong ^_~)
<jadahl>
gtk4 did indeed redesign much of its API to fit how Wayland works
<pq>
are other toolkits doing this, or likely to ever do it? Like Java stuff?
<pq>
So, everyone, I hope this discussion has spurred ideas of how you can justify killing my RFC. Please, do that with passion, but do make well-thought conscise arguments to justify why it should never be done. :-)
<pq>
then we can point to that RFC and show it was shot down, any time anyone comes crying about these things or proposes something similar again
<ofourdan>
that might not be enough for "Wayland", but at least for Xwayland (because Xwayland in not 100% -bug for bug- compatible with Xorg)
<pq>
ofourdan, nice
<jadahl>
pq: a differenc compromize is to put things 'ext_zones' in that new namespace, but still try hard to just replicate X11 and reintrudece plain 'set_position', active grabs, O-R windows etc
<davidre>
pq: In hindsight, toolkits should have designed new APIs that match Wayland idioms well as the first thing, roll those out to applications and remove the old APIs, and then actually port to Wayland. B
<jadahl>
try hard to *not* just ...
iomari891 has joined #wayland
<davidre>
This is easier said than done as Wayland is sometimes only one of many backends that the tollkit targets
<pq>
davidre, indeed, but who would know those targets better than the toolkit's people.
<ofourdan>
davidre: I am, not sure, realisticly, apps would not have adopted the new toolkit version / api as its doesn;t fit their need (just like now) and we would be at the same point, I reckon.
<davidre>
So of course it would be nice if the toolkit had a descriptibe interface that could be more easily transltated to Wayland but in reality it doesnt have enough pressure
<ifreund>
davidre: the nice thing about wayland's approach of policy over mechanism is that the wayland client API allows for quite straightforward translation to mechanism-based APIs of other desktops
<ofourdan>
we tend to always understimate resistance to change, even more so when the change is disruptive whereas benefit of the change is not immediately visible.
<davidre>
And another thing that toolkit maintainers (differing between toolkits) value is API stability so that even if there is a major version change, porting kept to be mostly straightfoward
<davidre>
Changing the toolkit API away from set_window_position(x, y) is a hard sell when every other platform that the toolkit targets works that way and the toolkit API has been like that for 20 years
<davidre>
I actually have not fully made up my mind about pq's proposal yet just wanted to chime in with that
kts has joined #wayland
<davidre>
If you are a linux only toolkit of course i would be easier :)
<emersion>
there are other platforms with heavy restrictions as well: iOS, Android, Web, etc
<davidre>
What I can say however that the descriptive approach is much nicer
<davidre>
We saw that with popups wherethe "manual" approach resulted in a big amount of code for positioning, keeping on screen, etc depending on the widget
<davidre>
emersion: True. I think it boils down to expecation managment for the user of the API
<davidre>
On android nobody has the idea to build a multi window app and be able to position those windows
<davidre>
for example
<Decker>
termux X ?
<davidre>
Printing "warning this function no-ops" or putting in the docs that it does not work on Wayland is a way
<davidre>
but does not help those people either
<davidre>
As I said I dont have made my mind up yet and I also dont knwo where I am going with this train tought :D
<ofourdan>
same here, fwiw.
<ifreund>
Maybe the solution is to provide alternative, policy-based APIs in the short term and link to them from the set_position docs?
<davidre>
I think if compat things came to be it would be a way to have applications opt-in to the niceties of wayland while they may be blocked on real issues
<davidre>
But I also see all the mentioned problems with it
<davidre>
We saw the drama when a compositor doesnt implement a new protocol
<ifreund>
I personally have no intention to support compat protocols in my compositor, due to a mix of not having time to maintain additional ugly code and idealism
<Decker>
and certainly if set position - the ability to get the display layout (x,y,w,h,id) of each display, and maybe an indicator of a primary display
<davidre>
I dont want to imagine what happens if a compositor chose to remove support for a compat protocol and breaks some app
<ifreund>
I worry that the introduction of compat protocols could therefore have a large negative impact on users of my compositor if e.g. qt starts requiring them
<Decker>
but I suppose wayland doesn't know 'primary'
<ifreund>
I really don't want to see a situation where compositors are effectively forced into implementing compat protocols because the ecosystem demands them
lbia has quit [Ping timeout: 480 seconds]
lbia has joined #wayland
kts has quit [Ping timeout: 480 seconds]
f_ has joined #wayland
fmuellner has joined #wayland
f_ has quit [Remote host closed the connection]
kts has joined #wayland
f_ has joined #wayland
sima has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
coldfeet has quit [Remote host closed the connection]
f_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
<mclasen>
late to this discussion, but since toolkits were mentioned: gtk4 has moved its apis to be modeled along wayland instead of X
<mclasen>
so for us, this discussion is about going back in time
<mclasen>
and the people that 'spit' on you will keep doing so even if you give them all they are asking for
<pq>
ack
<d_ed[m]>
Speaking for Qt we will not be changing any public APIs to match a platform. It's Wayland's job to meet requirements
<pq>
d_ed[m], when you chime in, would be nice to hear how Qt decides on what it requires from platforms, since Qt API is not modeled to for any platform.
<d_ed[m]>
will do
<pq>
thanks!
<swick[m]>
if windows or android decides to do something, toolkits will follow because they have no other choice
<swick[m]>
but they will do it
<swick[m]>
I don't believe when people say that platforms adjust to toolkits
dri-logger has quit [Ping timeout: 480 seconds]
dri-logger has joined #wayland
<Decker>
for games and signage it's still nice to say go full display at least err I guess there's a special shell for that somewhat
<pq>
Decker, special shell protocols were originally the idea for special environments, but nowadays it's more just xdg-shell compositor implementation adapted to the environment at hand, and apps just xdg protocols.
<Decker>
and doesn't a compositor get all surfaces to draw? it doesn't get a chance at mouse events to say where the mouse goes and maybe how it goes?
<pq>
the design of xdg protocols allows it to work in special environments, e.g. a kiosk compositor can just make all normal top-level windows fullscreen to begin with, and show only one at a time.
<daniels>
(and we have multiple of those compositors to choose from, one of which I know is shipped in both game and signage products)
<Decker>
gwsl for wsl just supports alpha transparent (pixel perfect) click-through ... but then the windows surface itself does it - and actually the gwsl does a really bad job at resizing with mouse
<pq>
Decker, a Wayland compositor fully relays both input and output, so yes, it gets any and all app surfaces, and it is fully in control of what input events the app can get.
<Decker>
so - wouldn't it just be a mod to weston to support transparent click through?
<Decker>
and really nothing at all with security because that pecie has all that inforoamtion anyway
<pq>
transparent click-through? I mean, Wayland explicitly has the app set an input region on its surfaces, and pixels not included in that region will be clock-through, transparent or not.
<pq>
*click-through
<Decker>
ya that's potentially less feasible for rounded windows or abstract windows with many transparent and non-tranparent regions
<pq>
it makes the region more complicated to represent, sure
<Decker>
so the compositor has the alpha in the surface bitmap... it can make a simple test if !alpha don't click
<pq>
the compositor could, except reading back alpha channel to the CPU for input routing decisions is expensive
<pq>
assuming its a dmabuf, i.e. hardware accelerated rendering of the window
<pq>
usually one wants to avoid copying data between CPU and GPU domains as much as possible
<Decker>
sure...
bindu has joined #wayland
<Decker>
I'm just reflecting on 'the other system is also hardware rendered and lives mostly in GPU so... it's being done without a great deal of impact on the system what's the difference'
bindu_ has quit [Ping timeout: 480 seconds]
<Decker>
easy enough to make a bitmap at 32:1 compression too on the way through I don't think a client is going to get GPU memory pointer it's going to be in CPU memory anyway at the message level
<Decker>
and message handler
<pq>
sorry?
<mclasen>
it is common for clients to deliver content via dmabufs, no cpu memory involved
<mclasen>
the 'bitmap' you want is the input region
<Decker>
it's only been an available feature since 2000... whenever XP waas, and Vista added a slight improvment with the ability to update only regions of a transparent window - and there's a separate style for mouse-transparent that checks the alpha and skips the winodw entirely if transparent - even if it's say an opengl rendering
feaneron has joined #wayland
<Decker>
actually I'm probably wrong about the opengl part - I think it ends up with an always forced surface alpha - though I vaguely remember actually getting a transparent 3d scene rendered with something. It definitely works with having a bitmap and outputting the bitmap regions to update (including the whole thing).
<Decker>
Which then means maybe I'm just asking for one corner case that can work, and it's being abstracted to 'it wouldn't work in all cases'
kts has joined #wayland
<daniels>
Wayland already provides clients all the tools they need to communicate these things
kts has quit [Remote host closed the connection]
kts has joined #wayland
dri-logg1r has joined #wayland
dri-logger has quit [Ping timeout: 480 seconds]
<Decker>
danieldg in a barely sufficient sort of way. We should all still program using Logo.
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
checkfoc_us has quit []
checkfoc_us has joined #wayland
julio7359 has joined #wayland
<JoshuaAshton>
emersion: I am so sorry for just pasting like 1000 lines of ASAN spew in our DMs. I imagine it's still going or something, I meant to paste the paste.froggi.es link but didn't copy it in my clipboard LOL