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
rasterman has quit [Quit: Gettin' stinky!]
soreau has quit [Read error: Connection reset by peer]
mceier has quit [Remote host closed the connection]
mceier has joined #wayland
soreau has joined #wayland
pnowack has quit [Quit: pnowack]
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Seirdy has quit [Quit: exiting 3.2]
tdeo has quit [Remote host closed the connection]
tdeo has joined #wayland
Seirdy has joined #wayland
<yrlf>
I think for the time being I'll stick with export-dmabuf, since I have not yet encountered any problems with it yet, and the added benefit of leaving the frames on the GPU is nice
<yrlf>
but if I ever do, I will remember to try screencopy :)
<yrlf>
I think I got the hang of the transforms now, thanks everybody!
<yrlf>
any1: ad shader code: that is literally what I had before switching to a transformation matrix to be able to handle y-invert, output transforms, and user-provided transforms at once
d42 has quit [Read error: Connection reset by peer]
d42 has joined #wayland
CME_ has joined #wayland
CME has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
cnsvc has quit [Quit: %bye%]
cnsvc has joined #wayland
aquijoule_ has joined #wayland
richbridger has quit [Ping timeout: 480 seconds]
aquijoule_ is now known as richbridger
Seirdy has joined #wayland
cvmn has joined #wayland
slattann has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
leon-p has joined #wayland
danvet has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
alexmitchellmus_ has quit [Remote host closed the connection]
<pq>
swick, no, not really. #247 should keep its scope to the things I listed. If you want to add more, open new issues and (ask to) tag them with "Protocol-next" label.
<pq>
romangg, ^
<romangg>
pq: ok, should I remove the comment and move it into a separate issue?
<pq>
swick, romangg, we now have lots of experience that Gitlab discussions can and will explode to a forest of hundreds of comments even if the topic is scoped, and letting the scope widen is not going to help readability.
<jadahl>
pq: the pixel color document is a work of art btw, a pleasent and insightful read
<pq>
any1, I would very much recommend against conflating buffer transforms with Y_INVERT. They are two different things set by different actors (application vs. GPU driver, so to say) so they do need to be set separately.
<pq>
any1, also, buffer transform does not dictate the geometric transformation alone. The actual geometric transformation is the transformation *from* buffer transform *to* output transform.
<pq>
any1, there is no screencopy for clients, did you mean glReadPixels with an off-screen surface?
<pq>
or with an FBO
<pq>
romangg, that would be nice - leave a link to the new issue in the comment you edit just in case.
<pq>
jadahl, thank you! Happy to hear I didn't lose into the "color science speak" yet. :-)
<jadahl>
pq: not sure how close to the brink of discolored insanity you are, but seems not there yet :)
fmuellner has joined #wayland
hardening has joined #wayland
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #wayland
<yrlf>
pq: the context for my question was a client that mirrors an output onto its surface (currently using export-dmabuf), so screencopy being only for copying from compositor to client is not a problem
<yrlf>
so if I understand this correctly, the transformation goes like this:
<pq>
in that case I would expect screencopy to be implemented through dmabufs
<yrlf>
- from physical dmabuf content space to 'logical' dmabuf space, if Y_INVERT is set flip the y coordinate, otherwise identity
<emersion>
note, export-dmabuf and screencopy are two wlroots protocols
<yrlf>
- from logical dmabuf space to output space, use the transformation from the 'transform' property of the output
<pq>
oh! I did not expect export-dmabuf to be a specific extension.
<yrlf>
emersion: ahh yes, that should be mentioned yes
<yrlf>
in my case that's probably not a problem, since my project explicitly works around sway's non-support for output mirrroring, which most other compositors implement natively as far as I know
<pq>
yrlf, I'm not sure output transform should be taken into account there. Such a simple statement seems to be missing more context.
<pq>
one can also use KMS properties to rotate/flip the image when display hardware supports it
<yrlf>
in my case I want to present the content of an output to the user on another outpur, but in the same orientation that the other output has logically. that's why I add the outpur transform
pnowack has joined #wayland
<pq>
that means the orientation of the framebuffer may not match the output transform
<emersion>
yeah, and… this might confuse clients
<pq>
what I think would be most clear is if the interface to grab the output image would either deliver the image always up-right, or it explicitly communicates the orientation.
<emersion>
if your wl_output.transform is set to 90, it might be tempting for the client to render pre-roatted
<emersion>
pre-rotated*
<yrlf>
I think there might be some confusion here: I am writing a client, and all these questions are from the perspective of a client
<emersion>
but if the compositor blends the client buffers, and uses KMS to rotated the result, it's better for the client to render non-rotated
<pq>
right, direct-scanout of client buffers that already have some buffer transform is another issue
<emersion>
to rotate*
<emersion>
pq, in this case the client buffer isn't scanned out
<pq>
emersion, sure, but if it is, it an issue :-)
<emersion>
it's just that the client is actually picking a less optimal path by using the wl_output.transform
<pq>
I did not think we were talking about how original clients should draw their buffers. That would be unrelated for the output image grabbing.
<emersion>
yeah, but for the direct scan-out case, easy enough to not set the rotate prop if the client has pre-rotated the buffer
<pq>
sounds like you are talking re-displaying the output image instead?
<emersion>
well, it's another case of things going south when KMS rotation is used and wl_output.transform confuses clients
<pq>
yeah, but that's just not optimal, it doesn't produce an outright wrong result, does it?
<emersion>
right
<pq>
I'm talking about wrong results.
<emersion>
i think a screen capture protocol needs to advertise the transform of the buffers explicitly
<pq>
yes
<pq>
Getting an image from an output as an export or a 1:1 copy and assuming that it is in the orientation of the output transform can produce wrong results in two cases: KMS is used to rotate, or direct scanout pre-rotated client buffer.
<pq>
yrlf, ^
<yrlf>
pq: thanks. so if I understood your discussion correctly, the current version of wlr-export-dmabuf does not expose a transform property that can reliably give me the correct behaviour?
<pq>
I can't say, I've never looked at that extension. Maybe it constricts the compositor to never use KMS rotation or direct-scanout to make things work?
<pq>
re-exporting a client dmabuf would have other problems too
<emersion>
yes, export-dmabuf forces a slow path atm
<emersion>
forces direct scanout and KMS rotation to be disabled
<pq>
lucky guess :-)
<emersion>
tbh maybe it's a good thing to force good old composition
<emersion>
KMS rotation is just the tip of the iceberg
<emersion>
you'll also want to add src/dst size and coords, alpha, etc
<emersion>
multiple buffers…
<pq>
color management is going to add a lot more fun there, too :-) "It's never just RGB."
<emersion>
yeah...
<pq>
one could pull an industry standard color space there, but that won't be optimal
slattann has quit [Read error: Connection reset by peer]
<pq>
and I'm not even talking about color but just the computational cost
flacks has quit [Quit: Quitter]
flacks has joined #wayland
d_ed has joined #wayland
zmike has quit [Ping timeout: 480 seconds]
zmike has joined #wayland
d_ed has quit [Ping timeout: 480 seconds]
<any1>
pq, yrlf: I misread and. For some reason I though wlr-export-dmabuf was being discussed
creich_ has joined #wayland
<yrlf>
any1: I do use wlr-export-dmabuf, so you guessed right :)
creich has quit [Ping timeout: 480 seconds]
<any1>
Well, that's good then. On the subject of keeping buffers on the GPU, screencopy can also do that. If you send it linux-dmabuf, it will blit to it on the gpu. It's still a copy, but not as bad as glReadPixels.
c7s has joined #wayland
d_ed has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
creich_ has quit []
creich has joined #wayland
<pq>
kennylevinsen, FYI, Meson 0.58.1 gives a couple of warnings on seatd.
<emersion>
the one about build_root() is a bit annoying
<emersion>
the feature to avoid the deprecation is only available in pretty recent Meson versions
<pq>
aha. There is also the other one about testing for linker flags.
<emersion>
yeah, that one looks like it should get fixed
c7s has quit [Quit: c7s]
c7s has joined #wayland
<pq>
emersion, kennylevinsen, how do you pass the wanted seat's name into libseat?
<emersion>
i think libseat decides it on its own -- and only logind has a concept of "seat name"?
<pq>
Looks like weston's launcher-libseat.c seat_open() ignores the seat_id parameter.
<pq>
I used to use that to make my test seat work.
<pq>
no, seat name is ID_SEAT udev property
<pq>
that's how everything filters the devices for a seat
<emersion>
libseat looks up XDG_SESSION_ID
<emersion>
and uses GetSeat on that session to find the seat name
<pq>
that is in the libseats logind backend, I'm not using that one.
<emersion>
oh
<pq>
I cannot use logind, because logind just can't deal with this use case.
<pq>
hence I used to use launcher-direct as a normal user
<pq>
and since libseat has the builtin backend, I was hoping that would work
<emersion>
it doesn't look like seatd/libseat cares about the ID_SEAT udev prop, or udev altogether
<pq>
weston cares though, and asks libseat to open only those devices. Something in the open path for a DRM device just doesn't work.
<pq>
I'm not even sure it's using the builtin backend.
<pq>
can I get more logging out of libseat?
CME_ is now known as CME
<pq>
what's libseat's "default" log handler? Is it not printing to std?
<emersion>
by default only prints errors iirc?
<emersion>
there's an env variable to change it
<emersion>
or you can programatically set the log level
<pq>
I tried with LIBSEAT_BACKEND=builtin SEATD_LOGLEVEL=3 but do not see anything printed.
<emersion>
SEATD_LOGLEVEL seems to only be used by seatd, not libseat
<kennylevinsen>
Yeah, right now seatd itself lacks a feature to configure additional seats/figure out which are set up in udev. When you do SEATD_VTBOUND=0 it makes the default seat not tied to a VT. Weston already knows what devices it wants, so it's not an issue that the default seat is more permissive.
<kennylevinsen>
Glad it worked out :)
<kennylevinsen>
Also it's LIBSEAT_LOGLEVEL=debug, not 3
<kennylevinsen>
(seatd does have machinery for multiple seats, but the "seatctl" or similar to configure them is lacking)
<pq>
there is no LIBSEAT_LOGLEVEL?
<pq>
well, it works, but telling libseat about the seat I want to take control of would be really nice.
novakane has quit [Remote host closed the connection]
novakane has joined #wayland
___nick___ has joined #wayland
apteryx has joined #wayland
<apteryx>
hello! Is this place suitable to discuss mutter?
<apteryx>
#Mutter on the gnome IRC seems very silent
<jadahl>
apteryx: #gnome-shell on irc.gnome.org
benbrown has quit [Quit: benbrown]
<apteryx>
alright, thanks!
benbrown has joined #wayland
leon-p has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
<kennylevinsen>
pq: doh, yeah, was thinking of SEATD_LOGLEVEL. libseat loglevel is up to the application.
___nick___ has quit []
<kennylevinsen>
seatd can't hard depend on udev for core functionality (freebsd and possibly soon openbsd/netbsd support is a pretty big part of the project), so a seatctl was an idea for one way to add/remove/modify seats.
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
<kennylevinsen>
Not the only idea though - another idea of mine was to make it possible to specify an executable that would take a device path and report its seat name. That would make non-racy udev integration easy. A plain configuration file for the seats would of course also be an option, albeit a boring one.
fmuellner has quit [Ping timeout: 480 seconds]
leon-p has quit [Quit: leon-p]
___nick___ has quit [Ping timeout: 480 seconds]
lmat has quit []
<DemiMarieObenour[m]>
jadahl: Thanks for the review!
<DemiMarieObenour[m]>
2. Support rootless compositors that cannot delay window resizing, merely respond to a resize that has already happened.
<DemiMarieObenour[m]>
1. Enable a UX provided by at least XFWM4 under X11, where the resize does not even start until the pointer has moved far enough (say, at least halfway to the next valid size).
<DemiMarieObenour[m]>
In particular, any rootless compositor with an X11 backend is in category 2 above.
novakane has quit [Quit: WeeChat 3.3]
<kennylevinsen>
I don't think 1 is a problem right now - a wayland client can react whenever and however it wants to the resize, including not doing anything before a resize is at least more than N larger, or only reacting to changes in increments
fmuellner has joined #wayland
<DemiMarieObenour[m]>
That is true. 2 is definitely a problem for at least Qubes OS, though.
danvet has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
<marmarek>
kennylevinsen: the use case is, as DemiMarieObenour[m] mentioned, a compositor that has (externally enforced) limits on what clients can do; in this model client can only ask nicely for some specific size
<DemiMarieObenour[m]>
In particular, the compositor itself is subject to these limits: it can ask nicely for a window size to be set to a certain value, but that is all.
ppascher has quit [Ping timeout: 480 seconds]
wolfshappen has quit []
Wanderer has joined #wayland
Erandir has quit [Read error: Connection reset by peer]