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
<DemiMarie>
Are there compositors that can position window borders on arbitrary physical pixels, even on HiDPI displays?
eroc1990 has quit [Remote host closed the connection]
eroc1990 has joined #wayland
dcz has joined #wayland
<kennylevinsen>
DemiMarie: compositors with floating point coordinate systems should be able to position windows on arbitrary physical pixels
fahien has joined #wayland
<kennylevinsen>
But generally the goal with scaling is to give you the same experience as if you just had a lower resolution (I.e., bigger stuff), but with the increased clarity of extra pixels. Addressing physical pixels in layout is not something that gets a lot of focus outside of avoiding rounding glitches
<kennylevinsen>
(being able to put more stuff on such screen is not a goal)
<vyivel>
i have a feeling that wl_subsurface.set_position2() with floating point coordinates should be able to fix most of the issues we have with the current approach
<vyivel>
this leaves input/opaque regions, but that's not nearly is important to get 100% precise
<vyivel>
s/is/as
rgallaispou has joined #wayland
<zamundaaa[m]>
It still fails with (sub)surface sizes though. Precise positioning doesn't help if surface sizes are in weird steps
<zamundaaa[m]>
if you require compositors to use floating point coordinates to make it work well anyways, you might as well make the jump to proper pixel coordinates, and make life a lot easier for clients
luyn has joined #wayland
<vyivel>
maybe update viewporter to support floating point sizes?
Dami-star has quit []
Dami_Lu has joined #wayland
rasterman has joined #wayland
<zamundaaa[m]>
I don't think that would work. When the client calls surface_damage for example, would the fractional parts be included or not?
<vyivel>
eh
<vyivel>
!149 sounds pretty simple on the idea level, and is more or less what i'd like to go with as well, but implementing that will quite an intrusive change
<vyivel>
i might try to hack something up for wlroots, idk
flibit has joined #wayland
manuel1985 has joined #wayland
flibitijibibo has quit [Ping timeout: 480 seconds]
<kennylevinsen>
zamundaaa[m]: I was planning to take a look at your proposal when time permitted - I wonder if it could be made more palatable
<kennylevinsen>
the "runtime selectable rounding algorithm" component away some of the simplicity in the "simple" proposal...
<vyivel>
imagine tracking damage caused by algorithm updates
sstiller has joined #wayland
<kennylevinsen>
i'd forgive a compositor for bailing out and damaging the entire geometry + error margin in that case :P
eroux has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<zamundaaa[m]>
kennylevinsen: its scope could probably be reduced to make compositor implementations easier. I think that ultimately having everything scaled instead of just what's strictly necessary is the less error prone variant though
<JoshuaAshton>
I got the new xwayland surface association protocol working
<ofourdan>
nice!
<JoshuaAshton>
ofourdan: Are you interested in reviewing protocol/xwayland impl at all?
<ofourdan>
sure!
<ofourdan>
best is to file a mr upstream
<JoshuaAshton>
I saw there was other xwayland protocols in wayland-protocols, so I worked out of there for now
<JoshuaAshton>
Cool, I have xwayland impl + gamescope impl too
<ofourdan>
also, we'd need to determine whther we wanthte wl protocol to sit in xserver/xwayland (as this is specific to xwayland) or if'd be better suited in wayland-protocols (as it would get better exposure for wayland compositors to find)
sozuba has joined #wayland
<JoshuaAshton>
Probably wayland-protocols, much easier for compositors to find + there already are xwayland protocols there
<JoshuaAshton>
like keyboard grab
<ofourdan>
yes
<ofourdan>
at some point, I was thinking of moving the xwayland keyboard grab protocol to the xserver/xwayland repo precisely becauset his is very specific to one given client (xwayland).
<wlb>
weston Merge request !583 closed (Draft: Parse static HDR metadata from the EDID)
Major_Biscuit has quit []
<daniels>
zamundaaa[m]: 'proper pixel coordinates' just reintroduces every single issue that using DIP causes, but in reverse
<daniels>
ofourdan: I think moving them into wayland-protocols makes sense
Vanfanel has joined #wayland
<Vanfanel>
How can I tell if a weston_view is the main view of a surface, please?
<DemiMarie>
daniels: the idea is that clients that are aware of DPI can take advantage of it
<DemiMarie>
vyivel: I would be interested in seeing the wlroots MR.
devilhorns has quit []
<daniels>
DemiMarie: ... and then reintroduces issues
<DemiMarie>
daniels: such as?
<daniels>
DemiMarie: what happens on mode switch?
devilhorns has joined #wayland
<DemiMarie>
daniels: require a client to choose before doing anything?
<DemiMarie>
Set it when creating a surface and never again afterwards
<DemiMarie>
If the client has done anything with the surface they get disconnected.
<DemiMarie>
!143 just seems much more complex than !149.
<daniels>
destroying the surface when you drag it between outputs, or when the user changes their scaling factor, also doesn't seem great
tanty has quit []
tanty has joined #wayland
trepatud1 has quit [Ping timeout: 480 seconds]
spuc950913 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
daniels: what do you mean with "mode switch"?
<pq>
Obviously we need to use pixels/radian and not dots per inch, because that's how the physical geometry works.
<pq>
Luckily the physical geometry should be irrelevant and we need to use unitless scaling factors. :-)
<daniels>
zamundaaa[m]: the output that was 180% is now 300%
<zamundaaa[m]>
The compositor sends the changed scale factor, and if/once the client adjusts to that, it sends the matching client side scale factor
Plagman has quit [Remote host closed the connection]
<zamundaaa[m]>
Just to clarify, the protocol doesn't at any point use actual pixel coordinates. It only allows the compositor to adjust the communication coordinate system so that it matches up with the output a given surface is on
<vyivel>
wl_surface.damage + space scaling would be annoying
spuc950913 has joined #wayland
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #wayland
tanty has quit []
Plagman has joined #wayland
<zamundaaa[m]>
It doesn't matter too much. Damage needs to be stored as a fractional value internally anyways, just like surface size
<kennylevinsen>
zamundaaa[m]: re: weird steps for positioning, as long as the client is aware it can offset stuff if the size increments are off. It should only be a problem if it happens behind the clients back, like rounding
<kennylevinsen>
daniels: I'm a little curious about that other proposal primarily becuase of the increased complexity from rounding logic which deviates a bit from the original "good enough" ideology... :/
<kennylevinsen>
still not convinced it can be made as simple, but eh - doesn't hurt to look
<zamundaaa[m]>
Hmm it would work but the client would need to add invisible pixels for the overlaps. Don't think that's doable on a toolkit level
rasterman has joined #wayland
<kennylevinsen>
I wasn't thinking invisible pixels, I was just thinking layout adjustments. E.g., shift the thing 1 physical pixel left (using fractional position) to compensate for size
<kennylevinsen>
when doing layout at arbitrary non-integer scales the client needs to deal with odd effects of rounding anyway, so might be fine? idk