01:17 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?
01:40 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
01:50 chapatt: riteo: Hmm, it seems wl_surface_listener doesn't have a member .preferred_buffer_scale. Is my library just out of date?
01:51 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
01:52 chapatt: Or if I have to save the globals, and later correlate with the surface enter/leave events. But comparing pointers seems wrong
02:46 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.
02:47 Company: you'll need to track all the outputs and their scales then
02:47 Company: and correlate them
07:32 MrCooper: pq: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/194#note_2388426 is an example of toolkit developers already considering to just use a "compatibility" protocol and call it a day
07:42 ofourdan: that's pretty much unavoidable I think, as soon as such protocols get added, people will use and rely on them.
07:46 emersion: some regular client wasusing the wlroots privileged output configuration protocol just to get a fractional scale of an output
07:47 emersion: s/was/is/ probably
07:48 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.
08:00 jadahl: MrCooper: that is indeed bound to happen, no doubt
08:03 wlb: wayland-protocols Merge request !308 opened by Jonas Ådahl (jadahl) build: Bump version to 1.36 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/308
08:21 pq: MrCooper, ok. What's the alternative?
08:23 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
08:23 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.
08:23 MrCooper: and it's just about to take over from X as the most used Linux display protocol
08:27 pq: Is there really incentive to port to proper Wayland idioms? Is that even technically possible?
08:27 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.
08:28 pq: You've probably noticed that I'm utterly sick of trying to stop bad designs. I don't review protocol extension proposals anymore.
08:29 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'.
08:31 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.
08:34 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.
08:34 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
08:36 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?
08:36 zzag: pq: toolkits are between the hard place and the rock
08:36 zzag: at least I can say that for Qt
08:37 zzag: Qt can't just change/break its APIs
08:37 pq: isn't that because you have promised to support an API that just cannot work on Wayland?
08:38 zzag: pq: yeah, kind of. but those apis are broken now anyway
08:38 zzag: for example, popup placement is still a challenge in Qt
08:38 zzag: there were some attempts to address that
08:39 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
08:39 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?
08:40 pq: I mean, I'm suggesting a PR stunt, essentially
08:40 pq: OTOH, I'm really delighted to hear opinions against legacy compatibility extensions. :-)
08:41 pq: please pour them in the Gitlab issue, so that we can show they have been considered at least
08:42 pq: rather than "upstream" looking like they deliberately want to break everyone's apps
08:42 pq: ...for no good reason
08:43 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.
08:43 pq: and please make those comments well justified and explained
08:44 pq: pulling the plug on Xwayland, then?
08:44 jadahl: what do you mean?
08:45 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
08:46 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?
08:46 pq: zzag, okay.
08:47 jadahl: pq: Xwayland *really* is for backward compatibility, adding a compat namespace is backward compat in theory, but far from it in practice
08:48 pq: jadahl, I don't understand the difference.
08:49 MrCooper: one difference is that it's still just X, whereas Wayland "compatibility" protocols let clients pretend they've ported to Wayland
08:50 pq: right, and apps and toolkits already pretend that
08:50 pq: maybe that was the mistake
08:50 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
08:51 pq: ok
08:51 pq: (It's not me you need to convince.)
08:51 pq: that's why should put your opinions in gitlab
08:51 jadahl: pq: I just tried to explain the difference
08:51 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
08:52 jadahl: thats not really "opinions" of "nay" vs "yay", merely an observation of the likely outcome
08:52 pq: let me ask this: why did any toolkit ever jump on the Wayland bandwagon to begin with?
08:53 pq: why start on that horrible amount of work? There must have been extremely high pressure from something to make that happen.
08:53 pq: Where did that pressure disappear now?
08:57 jadahl: did it disappear?
08:58 pq: evereyone here seems very worried that toolkits stop making changes as soon as they can.
08:58 pq: so why did they choose to go to Wayland at all?
08:59 zzag: because it's a new flashy thing? :D
08:59 selckin: release of hidpi monitors
09:00 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.
09:03 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.
09:03 pq: *I would think/hope
09:03 jadahl: pq: the "every frame is perfect" slogan perhaps
09:04 jadahl: or the "ability to lock the screen when a popup menu is open"
09:05 pq: Would legacy compatibility extensions really take those away?
09:07 jadahl: that depends on how far those protocols go in terms of backward compatibility
09:08 davidre: Maybe toolkit developers were as sick as compositor developers of having to deal with X :D
09:09 pq: right
09:09 colinmarc: rewrites are like catnip for engineers
09:10 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.
09:11 ifreund: wayland has always been developed primarily by compositor authors no?
09:11 pq: I think so, and that may have caused the problem.
09:12 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.
09:12 pq: we know how that went with wl_shell as a MVP example, and how we then got xdg-shell
09:15 pq: I still remember some toolkit maintainers saying they won't look at Wayland until it's ready.
09:17 ifreund: heh, where "ready" is defined as feature parity with X perhaps?
09:18 pq: "you have a solution for everything that apps want to do" I suppose, yeah
09:20 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.
09:20 ofourdan: *redesigning
09:21 pq: ofourdan, that's cool.
09:21 ofourdan: (well, that's my understanding at least, I might be wrong ^_~)
09:22 jadahl: gtk4 did indeed redesign much of its API to fit how Wayland works
09:22 pq: are other toolkits doing this, or likely to ever do it? Like Java stuff?
09:24 ofourdan: well, java is actually amending its specs to allow for that, see the email Phil has forwarded to the wakefield mailing list https://mail.openjdk.org/pipermail/wakefield-dev/2024-April/000155.html
09:25 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. :-)
09:26 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
09:26 ofourdan: that might not be enough for "Wayland", but at least for Xwayland (because Xwayland in not 100% -bug for bug- compatible with Xorg)
09:27 pq: ofourdan, nice
09:27 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
09:27 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
09:28 jadahl: try hard to *not* just ...
09:28 davidre: This is easier said than done as Wayland is sometimes only one of many backends that the tollkit targets
09:29 pq: davidre, indeed, but who would know those targets better than the toolkit's people.
09:29 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.
09:29 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
09:29 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
09:30 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.
09:30 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
09:33 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
09:34 davidre: I actually have not fully made up my mind about pq's proposal yet just wanted to chime in with that
09:34 davidre: If you are a linux only toolkit of course i would be easier :)
09:35 emersion: there are other platforms with heavy restrictions as well: iOS, Android, Web, etc
09:35 davidre: What I can say however that the descriptive approach is much nicer
09:36 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
09:37 davidre: emersion: True. I think it boils down to expecation managment for the user of the API
09:38 davidre: On android nobody has the idea to build a multi window app and be able to position those windows
09:39 davidre: for example
09:39 Decker: termux X ?
09:39 davidre: Printing "warning this function no-ops" or putting in the docs that it does not work on Wayland is a way
09:40 davidre: but does not help those people either
09:40 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
09:41 ofourdan: same here, fwiw.
09:41 ifreund: Maybe the solution is to provide alternative, policy-based APIs in the short term and link to them from the set_position docs?
09:41 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
09:42 davidre: But I also see all the mentioned problems with it
09:43 davidre: We saw the drama when a compositor doesnt implement a new protocol
09:43 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
09:43 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
09:44 davidre: I dont want to imagine what happens if a compositor chose to remove support for a compat protocol and breaks some app
09:44 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
09:44 Decker: but I suppose wayland doesn't know 'primary'
09:45 ifreund: I really don't want to see a situation where compositors are effectively forced into implementing compat protocols because the ecosystem demands them
11:05 mclasen: late to this discussion, but since toolkits were mentioned: gtk4 has moved its apis to be modeled along wayland instead of X
11:05 mclasen: so for us, this discussion is about going back in time
11:07 mclasen: and the people that 'spit' on you will keep doing so even if you give them all they are asking for
11:08 pq: ack
11:08 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
11:10 pq: d_ed[m], https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/194#note_2389399
11:10 d_ed[m]: I have seen that
11:10 pq: cool
11:12 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.
11:13 d_ed[m]: will do
11:14 pq: thanks!
11:14 swick[m]: if windows or android decides to do something, toolkits will follow because they have no other choice
11:15 swick[m]: but they will do it
11:15 swick[m]: I don't believe when people say that platforms adjust to toolkits
11:31 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
11:31 wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.36 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/24e612f7d735 meson.build
11:31 wlb: wayland-protocols Merge request !308 merged \o/ (build: Bump version to 1.36 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/308)
11:34 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.
11:35 pq: *apps just use xdg
11:35 Decker: https://wayland.app/protocols/fullscreen-shell-unstable-v1 a quick search before I completed that sentence landed me here...
11:35 pq: yeah, that's from way before
11:36 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?
11:37 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.
11:38 daniels: (and we have multiple of those compositors to choose from, one of which I know is shipped in both game and signage products)
11:38 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
11:38 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.
11:38 Decker: so - wouldn't it just be a mod to weston to support transparent click through?
11:39 Decker: and really nothing at all with security because that pecie has all that inforoamtion anyway
11:40 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.
11:40 pq: *click-through
11:41 Decker: ya that's potentially less feasible for rounded windows or abstract windows with many transparent and non-tranparent regions
11:41 pq: it makes the region more complicated to represent, sure
11:41 wlb: wayland-protocols New tag: 1.36 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.36
11:42 Decker: so the compositor has the alpha in the surface bitmap... it can make a simple test if !alpha don't click
11:42 pq: the compositor could, except reading back alpha channel to the CPU for input routing decisions is expensive
11:43 pq: assuming its a dmabuf, i.e. hardware accelerated rendering of the window
11:44 pq: usually one wants to avoid copying data between CPU and GPU domains as much as possible
11:44 Decker: sure...
11:45 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'
11:46 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
11:46 Decker: and message handler
11:48 pq: sorry?
11:49 mclasen: it is common for clients to deliver content via dmabufs, no cpu memory involved
11:51 mclasen: the 'bitmap' you want is the input region
11:51 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
12:02 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).
12:03 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'
12:06 daniels: Wayland already provides clients all the tools they need to communicate these things
12:18 Decker: danieldg in a barely sufficient sort of way. We should all still program using Logo.
12:24 wlb: weston/main: Leandro Ribeiro * color: explain why we don't unset surface image description https://gitlab.freedesktop.org/wayland/weston/commit/4ee612253e8f libweston/color-management.c
12:24 wlb: weston/main: Leandro Ribeiro * color: handle image description whose creation gracefully failed https://gitlab.freedesktop.org/wayland/weston/commit/29e3af7ba201 libweston/color-management.c
12:24 wlb: weston/main: Leandro Ribeiro * color: handle image description that are not ready https://gitlab.freedesktop.org/wayland/weston/commit/c10ca00e1084 libweston/color-management.c
12:24 wlb: weston/main: Leandro Ribeiro * tests: do not assume that the image description is immediately ready https://gitlab.freedesktop.org/wayland/weston/commit/f982e989542a tests/color-management-test.c
12:24 wlb: weston Merge request !1501 merged \o/ (color: minor fixes to CM&HDR protocol implementation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1501)
13:50 wlb: weston Merge request !1510 opened by Leandro Ribeiro (leandrohrb) Misc fixes to weston-image client https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1510 [Clients]
14:21 wlb: weston/main: Pekka Paalanen * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/f982e989542ac21e8a56bad25a6710e5f7375867...27a8cbeed90f3f000ac59de3a527ac26f89b487b
14:21 wlb: weston Merge request !1510 merged \o/ (Misc fixes to weston-image client https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1510)
15:08 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
15:08 emersion: ;_;
15:08 emersion: i stopped receiving stuff
15:08 emersion: i assume you got d/c'ed
15:09 JoshuaAshton: >.<
15:09 alice: cute
15:14 wlb: wayland.freedesktop.org Merge request !79 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.36 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/79
15:14 JoshuaAshton: Guess who set a struct member after calling DecRef!
15:14 JoshuaAshton: <--
15:14 JoshuaAshton: :D
15:14 JoshuaAshton: oop
15:15 wlb: wayland.freedesktop.org/main: Jonas Ådahl * releases: Add wayland-protocols 1.36 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/1c2a5f3f6bbc releases.html
15:15 wlb: wayland.freedesktop.org Merge request !79 merged \o/ (releases: Add wayland-protocols 1.36 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/79)