ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
iomari891 has quit [Remote host closed the connection]
mclasen has joined #wayland
KarenTheDorf has joined #wayland
<KarenTheDorf>
Why are there both wl_keyboard_destroy and wl_keyboard_release and similar in wayland-client.h? Should I always use _release where supported?
kts has joined #wayland
<kennylevinsen>
KarenTheDorf: wl_keyboard_release, the destructor, was added later in version 3. wl_keyboard_destroy does not send a request, and just removes the object, so that's not what you want.
<KarenTheDorf>
Time to go check all the _destroy calls I've written actually call destructors of the same name. Urgh.
<kennylevinsen>
The destroy request is usually also the destructor - the protocol documentation wayland.app specifies this with the "type: destructor" tag.
<kennylevinsen>
The core protocol just unfortunately had them retrofitted to some objects as the release request
kts has quit [Ping timeout: 480 seconds]
<KarenTheDorf>
I'm guessing the oversight was because you don't actually destroy the *keyboard*, just the object representing it. Unlike e.g. a surface? (That's kind of moot as a client application though, just me guessing)
<kennylevinsen>
It's related to a raciness in objects removed by the server
<kennylevinsen>
If they are just deleted immediately, the client might still be making calls to the object after it happened but before the client learned that it was gone
kts has joined #wayland
<KarenTheDorf>
So a true destructor call using wayland-client.h will send a message to the server to destory the serverside object, as well as destroying the local proxy, right? While wl_keyboard_destroy and friends just deletes the proxy.
<kennylevinsen>
Yes. So before (some 8 years ago), the server would delete it all and tell the client that the seat global went away, expecting things to be fine.
<kennylevinsen>
Now, it now lets the client remove them gracefully, avoiding the race
<KarenTheDorf>
Riiight, oh yuck now I see the problem. My assumption was that objects exist on the server as stubs that do nothing if they 'go away'.
<KarenTheDorf>
I wasn't expecting the server to ever pull them out from under me, as you said that's a horrible race condition.
<kennylevinsen>
That's also the newer approach - when needed, the server goes from having a real object to having an inert placeholder until the client finally gets rid of it
<kennylevinsen>
ensures that nothing breaks
<kennylevinsen>
It's also a problem that is very specific to objects created and destroyed by the server (globals). The vast majority of objects are client owned, which have no such issue.
<KarenTheDorf>
Why is there a magic "+8" to map between wayland keycodes and xkbcommon keycodes? The spec just says it's "platform specific".
<kennylevinsen>
It's an X11 thing
<kennylevinsen>
X11, in the *very* early days, decided that all buttons was to be handled the same - the first 8 IDs being mouse buttons
<kennylevinsen>
So there's a +8 offset for keyboard events
<kennylevinsen>
I don't remember all the details, but that's the gist of it at least
<mclasen>
everything in X is space constraint
<mclasen>
those fixed size events
<mclasen>
from a different era
<kennylevinsen>
bits don't grow on trees, we can't waste 'em!
<kennylevinsen>
if only there was some middle-way between bit packing everything and "we'll just bundle a web browser. or two."
privacy has joined #wayland
<KarenTheDorf>
The more I learn about wayland the more refreshing it seems to be compared to X or Win32. It's like it's the only display server protocol designed this side of the 1980s.
<KarenTheDorf>
Okay there's also Mir's native protocol but we don't talk about that.
<KarenTheDorf>
Even Mir doesn't talk about that
<mclasen>
X was designed for remote operation on < 10mbit/s networks ...
alarumbe has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
alarumbe has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
alarumbe has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
iomari892 has quit [Ping timeout: 480 seconds]
<jadahl>
the /120 way of communicating fractional scale is a bit unfortunate. with 1.75 on a 4K screen, the actual scale to end up with an int monitor size is ~1.752, but that means the clients and the compositor get different idea of how a logical WxH sized actual buffer should be. how do other compositors deal with this?
Brainium has joined #wayland
Brainium has quit []
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
soreau has quit [Remote host closed the connection]
alarumbe has joined #wayland
rv1sr has joined #wayland
<zamundaaa[m]>
jadahl: we round the scale to 1/120ths on the compositor side
privacy has quit [Ping timeout: 480 seconds]
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
<kennylevinsen>
same in wlroots. If it was wl_fixed it would be the same but /255 :/
<kennylevinsen>
Well, in sway at least
Brainium has joined #wayland
<kennylevinsen>
We don't try to fit the scale to give int monitor size. I'm not sure if that's the right solution either to the problem of filling the screen when resolution isn't a multiple of the scale...
<mclasen>
seems like a thing that a protocol should have the answer to...
<kennylevinsen>
discussion and ideas welcome?
<kennylevinsen>
There's somewhat conflicting requirements between "use this exact scale for your integer logical cooedinates" and "fill exactly this amount of pixels"
* mclasen
is of the opinion that the core protocol should be in device pixels
<zamundaaa[m]>
mclasen: something something v2
<kennylevinsen>
asjusting the scale isn't the worst idea I gave heard, but it probably requires pretty arbitrary scale fractions and there's plenty of bugs related to even the limited fractions currently used :/
iomari891 has joined #wayland
<mclasen>
Company: this is a discussion you wanted to have
<emersion>
i'm really skeptical about core protocol being device pxels
<emersion>
pixels*
mart has quit [Remote host closed the connection]
<kennylevinsen>
I'm not sure if it would be a problem to use buffer coordinates for everything, but not super fond of having to support both in all interfaces
iomari891 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
there's some things that would be annoying - like, if a configure is in buffer pixels you also need to know what the compositor understands your scale to be if you want to get the logical size, which is needed if you want to change scale...
<kennylevinsen>
And without a dedicated scale ack you can't assume it's the last commited scale. But then you get into a dedicated separate scale communication protocol like I recall was the case for zamundaaa[m]'s V2 proposal, which is arguably more complex than just "work in all physical pixels"
<kennylevinsen>
we should just outlaw content on multiple monitors
<kennylevinsen>
Fixes everything
<mclasen>
yeah, thats another thing: just kill wl_output
<mclasen>
no monitors - no problems
<zamundaaa[m]>
wl_output doesn't change anything here
<zamundaaa[m]>
And if you want scale changes for things like zoom, neither does multi monitor
<kennylevinsen>
+1 to killing it, but yeah it's not the cause of this specific issue
<ifreund>
I too would love it if wl_output didn't exist
iomari891 has joined #wayland
<Company>
jadahl, mclasen, emersion, kennylevinsen, zamundaaa[m]: I have opinions (some pretty strong) on that topic with the recent experiences in GTK 4.14
Guest7098 has quit [Remote host closed the connection]
<Company>
we had some discussions in gnome-land about that, but I wondered about setting up a call to discuss that with more compositor people
agd5f_ has quit []
cool110 has joined #wayland
agd5f has joined #wayland
cool110 is now known as Guest7164
<Company>
one opinion is that applications need device pixels, and that means compositor and app need to guarantee that the pixels the app sends matches the device exactly
<Company>
so you can't use ~1.752, you need to use 1920/1097 (if that's what you actually want, and I don't think you should want that, you should rather not offer 175%)
<Company>
(but that's one of the less strong opinions I have)
Guest7164 has quit [Remote host closed the connection]
<daniels>
right, so you would fudge the scaling factor to one which doesn't suck for the target resolution?
<Company>
the thing where apps want device pixels is placing subsurfaces - if you do that with application units, you need a way to ensure those can be specified in device pixels
<Company>
daniels: yes, like Apple does I think
<Company>
daniels: only offer ones that properly divide width and height of the monitor
<emersion>
what if a surface is half on a 1x device, half on a 1.3 device?
<mclasen>
I think you never want that
<Company>
emersion: if that is a real concern, you need a way to tell the app and have it create 2 buffers (potentially via subsurfaces)
<mclasen>
it happens when dragging a window over, but its not a use case to design the protocol for
<Company>
yeah, it doesn't matter for transient operations if device pixels don't match
<Company>
same in the shell's overview
<Company>
or alt-tab overlay
<zzag>
pq: if the compositor creates a resource, introduces that object to the client and destroys the resource, then that object can linger in the client's object map. If a new object is created with the same id, then the client will be terminated. Is this expected behavior or an oversight?
<zzag>
oh
<Company>
emersion: there are 3 use cases for device pixels: 1. text hinting, 2. raster image viewing (certain apps care a lot that the image looks good) and 3. retro games that want to use a NEAREST-like filter
<zzag>
and the client is notified about the fact that the resource has been destroyed on the compositor side by a destructor event
<zzag>
so the client calls wl_proxy_destroy() when it receives the destructor event
<zzag>
actually let me write an example protocol to show the problematic sequence of events
<emersion>
none of these need device pixels at the wl level though?
<Company>
emersion: no - not necessarily
kts has joined #wayland
<Company>
emersion: device pixels come up with placement and sizing of surfaces and buffers mainly
<Company>
emersion: on the protocol level
<mclasen>
its just that we have a hard time guaranteeing them device pixels at the application level with current state of the protocol
<mclasen>
round wrong in one place, and you get a dozen "blurry text" bug
<mclasen>
s
<Company>
I don't have an opinion on device pixel usage on the protocol level atm
<Company>
that may change once I have an idea about the best solutions for open issues though
<Company>
like subsurface placement or how compositors should do scale factor selection
iomari891 has quit [Remote host closed the connection]
<Company>
actually, surface placement, too
iomari891 has joined #wayland
<Company>
because you can get seams if you want to attach 2 toplevels next to each other
<zamundaaa[m]>
the context for this was that we wanted to send a list in a Plasma-private protocol
<vyivel>
although the reasoning doesn't mention id reuse
<zamundaaa[m]>
destructor events are completely fine for that
<KarenTheDorf>
This ties in to my earlier question with "why does wayland client have wl_keyboard_destroy as well as wl_keyboard_release and friends", server getting to destroy objects is ick.
<zamundaaa[m]>
as there will never be a request on the list object
<ifreund>
KarenTheDorf: the answer to that question is "we messed up and forgot to add a destroy request before tagging wayland 1.0"
<ifreund>
(we as in the wayland community as a whole, I personally wasn't around back then)
mart has joined #wayland
<KarenTheDorf>
I know, was answered earlier. From what I understood if the server just pulls a wl_seat or one of it's capabilities, there is either 1) a race because the client might still be sending requests using that id, or 2) a server leak as the object has to stay as an inert stub forever. Hence the _release methods.
<ifreund>
personally, I have my clients just hard exit if the compositor doesn't support these basic fixes like wl_keyboard_release
<daniels>
zzag: you can't do that - you need to define a fun_v1.you_should_destroy_this_now event, and a fun_v1.destroy request
<ifreund>
KarenTheDorf: you're now talking about a slightly different issue, the fact that global removal is missing
<zzag>
daniels: got it. thanks!
<ifreund>
this one can't really be fixed on a protocol level but can be mitigated by compositors
<KarenTheDorf>
Is there a way to see what was added/changed in a specific protocol version (other than git blame on the xml)?
<ifreund>
for example wlroots waits for a while after sending wl_global.remove before actually destroying the global on its side
iomari891 has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
<vyivel>
KarenTheDorf: new stuff has "since" attribute
iomari891 has joined #wayland
<KarenTheDorf>
Not everything is "new", like e.g. keymaps now much be MAP_PRIVATE since wl_seat 7, wl_surface::damage being obsoleted, etc.
<daniels>
a good general principle for protocol design is 'nothing like wl_seat'
<KarenTheDorf>
daniels: I might have to quote that in a blog post. :D
tyzef has left #wayland [WeeChat 3.8]
<daniels>
KarenTheDorf: please feel free, along with a note that the person who wrote wl_seat is very sorry about it, and has learned a lot about good protocol design since then
iomari892 has joined #wayland
<KarenTheDorf>
The best protocol is always the one written with hindsight. The second best protocol is the one we have today.
<KarenTheDorf>
*stares at wl_shell*
<daniels>
tbf wl_shell was always intended to be a placeholder for a real shell protocol
<Company>
that's why we have the real protocols now, with the wlr prefix
iomari891 has quit [Ping timeout: 480 seconds]
<KarenTheDorf>
I'm impressed that wl_shell has actually been taken out back and shot by basically every compositor instead of remaining in existance forever.
rasterman has joined #wayland
<mclasen>
I've wondered if wl_output shouldn't share that fate
iomari892 has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Remote host closed the connection]
<Company>
a problem with wl_output is that it's unclear to me what the purpose of monitor/output APIs is for applications
<Company>
if the application doesn't even know where it is, why does it matter where it could be?
<ifreund>
I agree, it doesn't make any sense to expose wl_output in a ideal policy over mechanism world
<kennylevinsen>
Mostly none, except for some specific scenarios like screen recording or layer shell
<ifreund>
wl_surface.preferred_buffer_scale and similar events could replace it
<ifreund>
layer shell and screencopy could easily implement their own privelidged output listing
<KarenTheDorf>
xdg_set_fullscreen uses wl_output, but with hindsight that could be something that lives in xdg_shell somewhere instead of in wayland.xml.
<KarenTheDorf>
*xdg_toplevel_set_fullscreen
<vyivel>
xdg-output maybe
<ifreund>
I have no idea how clients are supposed to be able to meaningfully choose a fullscreen output
<kennylevinsen>
Yeah, that's only a vague hint anyway and an app has no good way of deciding where to be fullscreened in the first place
<ifreund>
I think "start window on output" belongs in compositor config
<ifreund>
xdg-output also shouldn't exist... there have been discussions of deprecating it/renaming to xwayland_output
<Company>
well
<Company>
you could decide to make outputs useful
<emersion>
some clients let the user select from a list with the wl_output description, or have a CLI flag with output names
<Company>
"this is a projector"
<Company>
"this is the primary output"
<Company>
stuff like that
<emersion>
what will apps do with this information?
<Company>
presentation apps will present on the projector for example
<mclasen>
its a nice touch
<emersion>
a "projector" as in the hardware device?
<Company>
and games will probably like to spawn on the primary
<zamundaaa[m]>
Company: the primary thing is a really bad example
<Company>
emersion: yeah, or "beamer" or whatever the term is for that
<emersion>
"projector" might not be a good idea, maybe i use a projector for something else than presentation
<zamundaaa[m]>
Games abusing the primary display thing for placement is a source of a lot of annoyance and uder facing issues
<emersion>
or i want to present on not-a-projector
<KarenTheDorf>
I mean, on my personal machines I just assume games will just fullscreen on the primary. If I want them elsewhere I have to change the primary... Some games let you pick from an in-app settings screen. Most don't.
<Company>
emersion: I was thinking about defaults, there's always corner cases where you want something else
<emersion>
Company: what i mean is that it'
<zamundaaa[m]>
Tagging the surface with "for presentation" makes much more sense than tagging the output
<Company>
but then, I was just trying to give examples for making outputs useful
<emersion>
Company: what i mean is that it's better to have a semantic hint, rather than a low-level one
<emersion>
"output good for presentation" is better than "this is a projector"
<emersion>
up to the compositor to set projectors as "good for presentation" by default if they like
<zamundaaa[m]>
I really wouldn't put that in the output
<zamundaaa[m]>
The compositor might want to not put normal windows on a projector by default for example
<emersion>
but yeah, maybe better to tag a surface as "this is dong presentation stuff btw" instead
<emersion>
doing*
<Company>
it depends on what the outputs are for - and if you want apps to meaningfully interact with them
<emersion>
that way it works if you unplug a projector and re-plug another one, for instance
<Company>
of course, most of the time, apps think that what they want to do with outputs is a good idea when it isn't
<emersion>
that's an issue yeah
<LaserEyess>
compositors can know what apps want to do "game", "present", and then apps can know "this monitor is good for presenting"
<kennylevinsen>
And yeah, when I'm presenting it's usually on a random meeting-room mounted flat screen. Detection for suitability could perhaps be "largest physical dimensions"
<LaserEyess>
is it not still up to the compositor to place the app on the output regardless of what the app requests?
<zamundaaa[m]>
LaserEyess: kind of, but ignoring the app's requested output can break legit usages
<LaserEyess>
well then you're stuck between "this is a feature users want" and "but it goes against The Wayland Philosophy™ to let apps do it"
<zamundaaa[m]>
Like right now we don't have the "for presentation" hint, so if you just place both fullscreen windows from LibreOffice Impress on a single screen, that would be bad
<Company>
but if you screw it up, it's also bad
<Company>
ie if you put the notes on the presentation screen so everyone can read them
<zamundaaa[m]>
Yes, but currently compositors don't really have more information than the apps to do it better
<LaserEyess>
well I have good and bad news about that mode of failure
<LaserEyess>
good news: people are used to it and won't fault wayland
<LaserEyess>
bad news: no OS gets that right
<zamundaaa[m]>
That's why I want a protocol with apps to tag their surfaces, so that we can do better when apps make use of that
<LaserEyess>
so basically extend content-type
<Company>
LaserEyess: more good news: it's how /r/livestreamfail came into existence!
<zamundaaa[m]>
I'm not convinced content type is the right protocol for that, but yes
<kennylevinsen>
LaserEyess: there isn't much value in adding a feature that would be wrong most of the time just because things are also wrong most of the time on other OS's and people are used to it
<zamundaaa[m]>
Something like it for toplevels
<kennylevinsen>
In that case, doing nothing is pretty much no different - just pretend it was a messed up auto-placement :)
<Company>
wl_always_broken_v1
<LaserEyess>
the feature is wrong in well defined ways, though, and more importantly it's sort of expected by end users, as sad as that is for the ecosystem
<LaserEyess>
not that wayland can't do better
<LaserEyess>
but the status quo is what people live with every day
<emersion>
zamundaaa[m]: EDID + user pref
<LaserEyess>
the status quo on other OSes*
<zamundaaa[m]>
emersion: I'm not saying the compositor can't figure out which display is a projector, but that it doesn't know which windows need to go on it
<Company>
if we go by other OSes we need wl_recall_v1 and I don't think we do
<KarenTheDorf>
Something like `xdg_toplevel_set_fullscreen_hint(_toplevel, XDG_FULLSCREEN_HINT_PRESENTATION)` instead of `xdg_toplevel_set_fullscreen(_toplevel, _output)`? (Or HINT_GAMING or HINT_WHATEVER)
<emersion>
zamundaaa[m]: right, that for sure
<LaserEyess>
Company: again, wayland can do better, but I don't think it can do it "well", not unless something like wl_recall_v1 did exist, or at least wl_read_the_users_mind_v1
<kennylevinsen>
LaserEyess: if I had to pick between known broken and nothing, I'd pick nothing because it's more predictable and the easier thing to have habits for...
<Company>
zamundaaa[m]: netwm_window_type_v1
<zamundaaa[m]>
KarenTheDorf: no, it should be independent of fullscreen or not
<Company>
I'm not sure that tagging doesn't end up a huge mess once the number of tags grows too much
<KarenTheDorf>
Fair enough, I'm just assuming the usecase from my experience (raw vulkan/opengl applications)
<kennylevinsen>
LaserEyess: But as the use-cases are already well-established so we have a reasonable chance and defining a protocol that if used right will actually do what the user wants
<kennylevinsen>
Instead of "most of the time, kind of"
<Company>
we should just put SSD on fullscreen windows, then users can move them to the right output themselves
<Company>
problem solved!
<daniels>
presentation apps have a 'switch displays' button for this exact reason
<zamundaaa[m]>
Company: you can already move fullscreen windows in KWin
<daniels>
you can't always get it right, but you can try to get it right as often as possible
<zamundaaa[m]>
If you hold Meta, you can just drag them between screens. But it's not something the user should need to do
<Company>
zamundaaa[m]: I always assume that KDE can do it, but also that most people wouldn't know how
<daniels>
and yes, declaring intent on the surface ('this is my presentation window') is much better than declaring properties of the output and having the app say 'use this output'
<Company>
daniels: the app cannot show a different UI with that though - adding a "Maximize on presentation output" button for example
<zamundaaa[m]>
Company: yeah, this one is pretty hidden. As a more visible and intuitive thing, you can move them between screens in the overview
kts has quit [Ping timeout: 480 seconds]
<KarenTheDorf>
Watch the world burn: Add SSDs to Mutter, but only when fullscreen.
<mclasen>
what other tags would there be, apart from 'presentation' ?
<kennylevinsen>
"definitely not presentation oh God please don't share this"?
<kennylevinsen>
The content type thing has "game"
<Company>
"put on main monitor" and/or "put on side monitor" maybe
<Company>
like, OBS should probably go to the side
<kennylevinsen>
A non-presentation, auxillary/control/notes type window would make sense maybe
<Company>
but you get into window relationships with that, too
<Company>
"this is a utility window for this other window"
<zamundaaa[m]>
kennylevinsen: sensitive content could be a valid hint, yeah. Though it might make more sense to have that be in content type
<Company>
for multi-window gimp style stuff
<mclasen>
"zone 1"
<zamundaaa[m]>
about "game", if some compositor wants to have special placement for games, sure
<Company>
I think "game" is weird, because it's unclear what that means
<kennylevinsen>
Company: multi-window gimp feels like a whole other use-case though. A presentation doesn't feel like it needs association, it's just two windows of different types in different screens
<Company>
should the browser tag itself as "game" when I open a game website?
<kennylevinsen>
For content type, game is about low-latency mode for monitors
<kennylevinsen>
Theoretically?
<zamundaaa[m]>
kennylevinsen: I don't think any compositor uses it for that
<zamundaaa[m]>
but VRR and more lax rules for color accuracy with KMS offloading are good examples for how it might be used
<Company>
I wonder if that should be "low-latency" mode instead of "game"
<kennylevinsen>
zamundaaa[m]: tbf I'd want permanent game mode for any monitor having it to not get seasick from effective input delay :/
<zamundaaa[m]>
Company: if the browser opens a whole separate window exclusively for a game, sure. If not, then not
<Company>
solitaire is a game but doesn't want low latency
<LaserEyess>
I think they're separate usecases, but low-latency is a good content type
<Company>
the testufo is not a game but wants low latency
<emersion>
it's not a content-type
<zamundaaa[m]>
kennylevinsen: KWin just always sends "graphics", which is supposed to make TVs detect the input as a PC. I haven't been able to test it though
<emersion>
a content type is a high-level hint
<emersion>
"i want low latency" is a lower level one
soreau has joined #wayland
<LaserEyess>
it's also monitor specific, which goes back to "I am an app that is a game and wants to be placed on a low latency, high refresh rate monitor"
<LaserEyess>
which would be nice to be able to specify
<Company>
I don't think people want their games on the "low latency" monitor though
<LaserEyess>
yes they do
<Company>
they want their games on the monitor they play games on
<LaserEyess>
those are usually one and the same
<zamundaaa[m]>
From bug reports about the annoying "primary monitor" thing, people want games to start on the monitor that they start the game on
<Company>
I'm not sure they're the same
<Company>
I don't even know which of my monitors has the lowest latency
<LaserEyess>
well if we're talking about real world examples, it's not really something you can actually know
<kennylevinsen>
Stuff *not* starting on the focused output is one of windows most frustrating behaviors...
<LaserEyess>
you can only use surrogates
<Company>
we should just train an AI
<Company>
and let it decide the monitor to place windows on
<Company>
problem solved!
<LaserEyess>
and now we're back to wl_recall_v1
<KarenTheDorf>
Windows generally seems to start stuff on the monitor that had focus on launch. *Except* full screen programs (games) that always seem to open on the primary.
<Company>
Windows starts stuff on the monitor where the mouse pointer is
<LaserEyess>
not always, which is indeed a real PITA when using it
<zamundaaa[m]>
Where Windows starts stuff barely matters, when a decent chunk of apps are "smart" and remember their position for you. Even when it's on the wrong display
<Company>
apps remembering things only works if your monitor config is static
<kennylevinsen>
that we don't let them do that is one of the best Wayland features
<zamundaaa[m]>
I've even had an app remember its position so well that it placed its window on a screen that wasn't connected anymore. Luckily we don't have those sorts of problems on Wayland
<KarenTheDorf>
Company: Yeah, I've had apps open up outside the bounds of my monitors before now after a reconfiguration.
<LaserEyess>
ok how about this as a usecase: I frequently plug in my laptop to an external monitor to run mpv on, and I have to focus the external monitor before mpv opens otherwise it will start on my laptop's screen. But it's a pretty clear intent to have a media player run on the giant monitor/tv that was just connected
<LaserEyess>
it would be nice if the compositor could let mpv start on the bigger monitor with some hint
<LaserEyess>
I think this is something that no other OS does right, but that wayland could theoretically do right given content-type as well as another protocol for the compositor to let apps know some properties of the monitor
<zamundaaa[m]>
LaserEyess: letting apps know things about the monitor is not a good way to achieve this sort of thing
<kennylevinsen>
Hmm, not really. Case in point: My laptop monitor is obviously smaller than my desktop monitors, and if I open mpv on the smallest screen to play a video (the laptop), it's because I want it to play *there* as I'm doing something else on the others or don't want it to be as big when watching in the office.
<kennylevinsen>
If mpv used a hint I'd need to disable it or have my compositor ignore it
<kennylevinsen>
I feel that it's different than the more obvious presentation example at least
<LaserEyess>
it is different, hence bringing it up
<zamundaaa[m]>
LaserEyess: but if you want a "content type" for window placement, and have your compositor do something smart with it, I don't see why not
<LaserEyess>
zamundaaa[m]: but I need some way to know if this thing is a "TV" or "VR", or *something*
<zamundaaa[m]>
Why would the app need to know that?
<zamundaaa[m]>
The compositor controls window placement, and it has as much information about the displays as you can get
<kennylevinsen>
I guess mpv could let you specify the content-type, and if you thought it was presentation (your big screen would likely be the most presentation capable) you could ask for that. Or it could set it to video, and configure your compositor to use the big screen for video by default
<kennylevinsen>
(I'm a bit hesitant about the latter as it's not obviously the right thing due to many common video sources not justifying a forced cinema experience...)
<kennylevinsen>
Maybe "cinema" would be good to distinguish from a plain video source
<LaserEyess>
zamundaaa[m]: maybe the app doesn't need to know it, but I think generic "content-type" isn't enough
<emersion>
mclasen: sounds like just a GTK bug?
ongy[m] has quit [Quit: Client limit exceeded: 20000]
nickdiego[m] has joined #wayland
<nickdiego[m]>
fwiw, in chromium, which also has this sort of "monitor metadata" API, we're also dealing with similar issues
<mclasen>
yeah, sure but the bugs are caused by the messy situation of trying to combine some data from wl_output with data from xdg_output
<mclasen>
and dealing with different versions of those
<mclasen>
or their absence
<mclasen>
it is just all around far too messy for the little benefit that monitors offer
<nickdiego[m]>
actually, any toolkit/middleware (which browsers usually act as) which expose that kind of abstraction to clients are currently broken under Wayland I guess
<emersion>
just require the latest version of each and don't expose anything if missing?
<emersion>
yeah, supporting the full matrix is a mess
<nickdiego[m]>
what about backward compatibility? eg: stable apis on which apps rely on 👀
<nickdiego[m]>
not sure if xdg-toplevel-drag folks are around. I have a few quick doubts after giving chromium's patch a try
<nickdiego[m]>
kwin (sole impl of the protocol so far) sends data_source.dnd_drop_performed and then cancelled when the drop happens within "non-target" surfaces, is that WAI or a impl bug? afaict the spec is not clear about that
mart has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
Company has quit [Quit: Leaving]
privacy has joined #wayland
rv1sr has quit []
fmuellner has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
<kennylevinsen>
emersion: I'll follow up on the annoying yet-again-reopened issue in a minute, don't worry about it yet :P
<emersion>
was thinking about closing it + locking with a comment among the lines of "if you're not going to play by our rules, let's stop here"
<vyivel>
there should be a reply template specifically for csd lol
<vyivel>
i wonder if one could repurpose cage to add decorations to anything
<soreau>
what is the issue?
<kennylevinsen>
emersion: I'll respond once, then indeed lock if they keep going. Don't want others that trip over it to think they had a good idea and that we're somehow not cooperative enough to accept it, so want to cement it first
<kennylevinsen>
Considering the Factorio dev comment (which itself was fine) I wouldn't be surprised if other gamers came along, regurgitating such things blindly
<emersion>
i mean it's fine to continue discussing
<emersion>
but if they play the re-open issue game…
<jadahl>
zamundaaa[m]: so with a 1.75 (which is what the real scale would be rounded to), and a 3840 wide resolution, the logical width of the monitor would be 2194.3. how do you deal with that?
lbia_ has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
jadahl: with that particular value, there's nothing you need to deal with. 2194 * 1.75 = 3839.5, which rounds to 3840
<zamundaaa[m]>
But for values where it actually doesn't work out, well, there just are gaps in that case
<jadahl>
so you'll render and skip a pixel on the edge?
<jadahl>
of the monitor
<jadahl>
some how I want to travel back in time and add both a num and denom to not have to deal with this
<zamundaaa[m]>
That wouldn't fix it
DodoGTA has quit [Remote host closed the connection]
<jadahl>
it'd fix not getting logical sizes that doesn't align with the monitor mode
<zamundaaa[m]>
Sure, but apps aren't fullscreen that often. For a maximized window to fill the screen properly, you need the size of that + DE panels on the screen to add up to the full screen
dos11 has joined #wayland
mtretter has quit [Remote host closed the connection]
mtretter has joined #wayland
<jadahl>
could just make the panel height align with the physical grid
dos1 has quit [Remote host closed the connection]
<mclasen>
that would be cheating in a way
<mclasen>
if it end up using non-integral application pixel sizes for the compositor chrome
<mclasen>
i agree that ultimatively, that is what you want: sizes in device pixels
<jadahl>
so its better not being able to use the whole monitor?
<mclasen>
it would be better to start over from scratch on fractional scaling
<mclasen>
imo, what we have now is not salvageable
vsyrjala has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
<zamundaaa[m]>
jadahl: there's no "just" about it when the panel is just another Wayland surface
<jadahl>
true, that makes it trickier
fmuellner has joined #wayland
<jadahl>
if we could tell clients the best buffer size that might make that easier
vsyrjala has joined #wayland
sima has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
mvlad has quit [Remote host closed the connection]
<KarenTheDorf>
Urgh, I don't get the wayland event loop. Why do I have to manually poll an fd to see if there is anything on the socket to read? (Failure to do so gets a crash with "Error sending request: Resource temporarily unavailable")
<KarenTheDorf>
https://pastebin.com/02th3RZ6 is what I was doing, but kaboom. Doing a poll on the wayland socket and only doing read_events if it's ready for read fixes the kaboom but I don't see why fixing my empty reads prevents an error *sending* requests.
<daniels>
KarenTheDorf: you’re forgetting to flush
<KarenTheDorf>
Where should the flush be? (There's a flush in that code, after the prepare_read/dispatch_pending loop
<kennylevinsen>
See the docs for wl_display_prepare_read_queue which has an example of how to dispatch manually instead of using wl_display_dispatch
Guest7165 has quit [Remote host closed the connection]
kasper93 has joined #wayland
<KarenTheDorf>
Well, poll() in that example blocks forever, which is what I'm trying to avoid. I suppose the extra waiting is wnough time to avoid overfilling the send buffer?
<KarenTheDorf>
It works, but now the wl_buffer doesn't get updated unless I jiggle the mouse or similar.
<kennylevinsen>
poll blocks forever if nothing is happening. The point if that snippet is that you substitute poll with your own event loop, which might also wake for other things than Wayland traffic.
<kennylevinsen>
If the buffer is not committed unless you jiggle the mouse despite flushing before sleeping in poll, it seems like you render and commit path is borked. You're not using threads are you?
cool110 has joined #wayland
<kennylevinsen>
(if you don't substitute the poll, you might as well just call wl_display_dispatch in a loop which does the whole shebang including poll)
lanodan has quit [Ping timeout: 480 seconds]
cool110 is now known as Guest7190
<KarenTheDorf>
Only one thread
<kennylevinsen>
What is your trigger for rendering?
<KarenTheDorf>
Uh, there isn't one? It's a loop that sits in "while(!window.closed){ poll_events(); render(color++); }"
<kennylevinsen>
Yeah that doesn't make sense
<kennylevinsen>
Poll events without your own event loop means "wait until the server has something to say". It won't have something to say unless you ask it to.
<kennylevinsen>
If you want to render continuously at an opportune time, you'd subscribe to frame events for the surface and repaint in response to those as long as you think it makes sense to render.
<kennylevinsen>
(You'd then stop once there are no changes to render, and only restart rendering if the content would have changed - e.g., on keyboard input)
<KarenTheDorf>
If it has nothing to say, I'd expect it to just render the next frame early (which yes, means dropped frames and wastefulness, not ideal in a finished application but just what I expected to be able to do)
<kennylevinsen>
But you would never do poll(); render(); - the frame callback would be handled within the dispatch
<kennylevinsen>
That doesn't align with how poll works. It sleeps until the I/O event you asked for, and when rendering you're the one talking - not the server. Nothing to wake the poll.
<kennylevinsen>
Nothing stops you from polling with timeout though, just make sure you only read the Wayland connection when poll says it was readable.
<kennylevinsen>
(that's what an event loop would do for you anyway, not like you need to sleep forever just because the server doesn't have anything to say)
<KarenTheDorf>
I think I'm going down the wrong path by talking about poll. I think I fixed my code and it's not by using poll() but instead by sticking wl_display_flush() in a loop until it stops failing with EAGAIN.
<kennylevinsen>
Uhm
<KarenTheDorf>
Oh, only some of the time. Gah. I'm going to just punt wayland off to a background thread like I do with win32.
<KarenTheDorf>
Then it can block all it wants
<kennylevinsen>
Neither of those is right and you'll get a lot more pain from putting it in a thread
<kennylevinsen>
The right thing to do is just to use a frame callback, which is pretty easy. See wl_surface_frame.
<kennylevinsen>
Then wl_display_dispatch in a blind loop will work perfectly with properly refresh-throttled rendition, and unless you want to design an event loop, fidgeting with poll might not be the right way to spend time.
<KarenTheDorf>
Well, the idea of this was eventually I'd plug it in to a vulkan application. Which can run either with somethink akin to a frame callback (PRESENT_MODE_FIFO, might well use frame callbacks internally) but can also just run away and render faster than the screen (PRESENT_MODE_MAILBOX or IMMEDIATE)
<KarenTheDorf>
So I'm trying not to block in my wayland event handling, so that the vulkan side of things doesn't get forced to the refresh rate of the screen if it doesn't want to be.
<kennylevinsen>
Set the pool timeout to whatever you want, and your loop will run on any server event *or* if the timeout expires
<kennylevinsen>
It'll get your loop cranking, but at very irregular speed
<KarenTheDorf>
kennylevinesn: https://pastebin.com/pcAG8nsK This works, for now. But thank you for the link. Honestly, it is *incredibly* tempting to just say 'fps higher than the refresh of your screen is pointless' to users but... People like seeing 9001fps reported on a 60fps display :D
<KarenTheDorf>
I almost certainly want to poll for POLLOUT, rather than that busyloop.
<kennylevinsen>
Steal what you want :)
bodiccea_ has quit [Remote host closed the connection]