ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has quit [Ping timeout: 480 seconds]
kts has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
<danieldg>
Company: if you don't use any fractional-scale stuff, it just goes at (1,1) in the scale-2 copy of your window, which is then scaled down
<danieldg>
but if you put it at (4,4) then it should be fine
fmuellner has quit [Ping timeout: 480 seconds]
<danieldg>
if I were writing a compositor, I'd round subsurfaces to an integer alignment of true pixels if they use viewporter to make buffers with true pixels; but I'm not one
erydactyl[she] has left #wayland [#wayland]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
mbalmer has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
mbalmer has joined #wayland
<Company>
danieldg: I'm trying to think about how to implement a video overlay
<Company>
for GTK
<Company>
and that kinda requires that I get pixel-exact positioning or the rendering is gonna look wrong
<danieldg>
put both at (0,0) and there's no issue
<Company>
sure
<Company>
but I'm talking about making it part of the toolkit
<Company>
so that when somebody puts a video widget somewhere, it gets automatically put in an overlay
<danieldg>
you could still start the subsurface at a known-integer point and then just have it transparent and no-input outside the 'real' region
kts has quit [Quit: Konversation terminated!]
<danieldg>
that seems to be the only way to get guaranteed correctness atm
<Company>
can't do that because I want to attach() the video buffer directly
<Company>
and afaics the attachment point is always top left
<danieldg>
viewporter set_destination
<danieldg>
oh, sorry
<Company>
that's just width/height, no?
<danieldg>
yeah
<zamundaaa[m]>
If there's demand, I could revive my fractional-scale-v2 MR again, which works properly with subsurfaces
<danieldg>
Company: wl_surface::offset
<DemiMarie>
zamundaaa[m]: There is demand from me!
<DemiMarie>
For just this reason
<DemiMarie>
Company: this is a good reason for fractional-scale-v2
<danieldg>
fixing the protocol migtht be better, yeah
nerdopolis has quit [Ping timeout: 480 seconds]
<Company>
I'm not far enough into this process to actually know what I need
<Company>
peeling the dmabuf out of the render command tree is a fun task in itself
<Company>
one of the things that is rather relevant though - especially with fractional scaling - is the ability to express coordinates unscaled, to get pixel alignment
<danieldg>
yeah, if the protocol were being designed with fractional scale in mind, all integers would be in 1/120 pixel units
<Company>
especially because the whole rendering pipeline needs to operate on pixels
<danieldg>
it's not like anyone needs windows a billion pixels wide
<Company>
for things like glScissor() or so
<Company>
ugh, I'm just realizing that this all doesn't work
<Company>
because I don't want the window to resize when it moves outputs
<Company>
but if I move from a 100% to a 125% output, this might be necessary
<danieldg>
yes, if the actual pixel size changes, you'll need to render frames at that resolution
<Company>
that's not the point
<Company>
the point is that I can attach a subsurface at (1,1) with 100% scale but not with 125% scale
<Company>
so something will happen to that subsurface if it moves outputs, even if the app doesn't do anything
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
bbhtt- is now known as bbhtt
Satan2 has quit [Remote host closed the connection]
<DemiMarie>
Company: fractional-scale-v2 does what you seem to be asking for
<DemiMarie>
fractional-scale-v1 does not.
nerdopolis has joined #wayland
fmuellner has joined #wayland
psykose_ has quit [Remote host closed the connection]
psykose has joined #wayland
<Company>
I'm not even quite sure what fractional-scale-v2 is even doing
<Company>
do the compositor and client potentially use a different coordinate system there?
<Company>
also, is that 8.24 or 24.8 fixed point?
<Company>
and why is it not just using wl_fixed?
<DemiMarie>
I’m not zamundaaa, but my understanding is that fractional-scale-v2 changes the coordinate system used by the client **and** the compositor, so that physical pixels are used instead of logical ones. This is what allows subsurfaces to be aligned on arbitrary physical pixel boundaries.
<Company>
it looks to me like they both change coordinates on their own
<Company>
so everyone talks in their favorite coordinate system
<DemiMarie>
that is rather weird
<Company>
yeah, that's why I'm wondering
<DemiMarie>
Personally, I would have all coordinates be double-precision floating point with a pixels-per-inch scale factor
<Company>
I'm sure that would totally not ever cause rounding issues at all
nerdopolis has quit [Ping timeout: 480 seconds]
<DemiMarie>
This assumes that window placement isn’t a hot path, so it is done on the CPU and not on the GPU where double precision might not be available.
<Company>
the other issue that neither protocol solves is that moving the surface from one output to another output might change the desired rendering scale
<Company>
at which point pixel alignment will be busted anyway
<Company>
and I think using floating point is always a bad idea - no matter what precision - when talking about pixels
<DemiMarie>
If you care about multiple outputs my non-expert opinion is that one should just be using physical coordinates and explicit output identifiers
<DemiMarie>
In other words, applications would need to know which output they are on and render to each monitor separately.
<Company>
you can be on >1 output though
<DemiMarie>
exactly
<DemiMarie>
and those outputs will (in the general case) have different resolutions
<Company>
and this isn't about rendering (only) but about placement of subsurfaces, too
<DemiMarie>
I don’t see any way to have physical-pixel-perfect rendering and subsurface placement without informing applications about the exact portion of each surface that is on each screen
<DemiMarie>
In other words, applications would need to render to each output separately.
<DemiMarie>
That’s the X11 model IIUC
<Company>
the X11 model is "yolo"
<DemiMarie>
What do you want to happen when a surface is split between outputs?
<Company>
I don't know
<DemiMarie>
In that case I would start with the simpler 1-output case
<Company>
what I know I want to do is have a dmabuf that I don't touch
<Company>
because it comes from the video decoder/webcam/whatever and I just want to pass it through
<Company>
and then I want to draw my window chrome (titlebar, buttons, whatever) around/on top of it
<DemiMarie>
Can you do that at all without knowing where the dmabuf will end up?
<Company>
no, not really
<DemiMarie>
To use a concrete example: do you want to use peer-to-peer DMA to transfer data from a webcam to a discrete GPU?
<Company>
it will look glitchy
<Company>
ideally I want to not touch the GPU at all
<Company>
and use DMA between the webcam and the compositing hardware
<DemiMarie>
I meant “where” as in “which physical device”, not ”where on the screen”
<DemiMarie>
Are there devices where the compositor can be a DMA target?
<Company>
there's hardware layers on various mobile chips, though I'm no expert on which ones and how
<DemiMarie>
but are those layers memory that one can DMA to?
<Company>
dunno
<Company>
the important part is that the GPU isn't involved
<Company>
and I know that that works
<DemiMarie>
Do you have the simple case (shaders) working?
<DemiMarie>
Direct scanout of a dmabuf is going to be very platform-dependent
<Company>
in the simple case we just compose the dmabuf into our rendering pipeline
<DemiMarie>
36
<DemiMarie>
whoops, did not mean to send that
sima has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
<Company> "so everyone talks in their..." <- Yes, ish. The thing is that Wayland is asynchronous, so if the compositor would just tell the client "the new scale is 2", the client will not instantly know about the new scale and take that into account in its requests
<zamundaaa[m]>
So you need some way for each side to say what its messages mean, independently of the other side
<zamundaaa[m]>
Ideally the client should always switch to the compositor's coordinate space as soon as it receives the event about the changed ideal scale. And ofc it should also re-render its surface with that ideal scale asap
<Company>
yeah, in the usual case that's what should happen
<Company>
but I'm trying to figure out how to trick the system
<Company>
I think what I'm after is a way to place my subsurface relative to the pixels of the buffer I submit
<zamundaaa[m]>
Yes, that is what the protocol allows you to do
<Company>
so if the buffer has scale 125% I want to place the subsurface relative to that
<zamundaaa[m]>
If you say you're using the scale 125% as the coordinate system for the parent surface, the subsurface positions will be in that coordinate system
<Company>
I'm not even sure what coordinate system the parent surface is using
<Company>
what I'm interested in is the scale that the buffer is using
<Company>
which is kinda evil, because now I want to place the subsurface using that
<zamundaaa[m]>
If you set the coordinate system of the surface to scale 125% and attach a buffer, the buffer size will be scaled by that as well
<Company>
by default, yeah, but I'm using wp_viewport
<Company>
and we actually use 2x scale for rendering on 125% surfaces currently (though that is about to stop)
<zamundaaa[m]>
I'm talking about my protocol, not current Wayland
<Company>
I'd imagine even with your protocol and wp_viewport, that could happen
<zamundaaa[m]>
What could happen?
<Company>
that the scale I'm using for the toplevel surface is different from the buffer scale
<Company>
but I could apply the buffer scale to the subsurface
<Company>
at that point it depends on which functions are actually affected by the scale
<Company>
like, is subsurface.set_position() affected by the subsurface's scale or by the surface's scale?
rasterman has quit [Quit: Gettin' stinky!]
<zamundaaa[m]>
The subsurface position is a parent surface state, so it's affected by the parent surface's scale
nerdopolis has joined #wayland
<Company>
but I can of course use offset instead of position
<Company>
and offset is subsurface's state
<DemiMarie>
What could be done is to send a message to the compositor and wait for the reply before doing anything further.
<zamundaaa[m]>
why would you wait for a reply?
tristianc6704 has quit []
i509vcb has joined #wayland
tristianc6704 has joined #wayland
rv1sr has quit []
sevz has quit [Quit: WeeChat 4.1.0]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
___nick___ has quit [Ping timeout: 480 seconds]
c6ristian has joined #wayland
c6ristian has quit []
c6ristian has joined #wayland
c6ristian has quit []
c6ristian has joined #wayland
sevz has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
elderbear has quit [Quit: elderbear]
elderbear has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
AJC_Z0 is now known as AJ_Z0
c6ristian has quit [Quit: irc quit]
Company has quit [Remote host closed the connection]
Company has joined #wayland
fcarrijo has joined #wayland
fcarrijo has quit []
privacy has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
nerdopolis has joined #wayland
ecloud has quit [Remote host closed the connection]
ecloud has joined #wayland
<DemiMarie>
zamundaaa: to ensure that the new coordinates have taken effect
glennk has quit [Ping timeout: 480 seconds]
<daniels>
no, that doesn’t fix it
<daniels>
the only two ways you can eliminate race conditions are to have only one side which can ever change co-ord systems, or to use a serial/epoch system so you can detect desync
<daniels>
without either of those, roundtrips only add latency without solving the problem
<daniels>
Company: spb exists so we don’t have to have 1x1 shm buffers to do e.g. letter/pillarboxing