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
fmuellner_ has quit [Ping timeout: 480 seconds]
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
spstarr has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
paulk has quit [Read error: Connection reset by peer]
JEEB has quit [Server closed connection]
JEEB has joined #wayland
llyyr has quit [Server closed connection]
llyyr has joined #wayland
LaserEyess has quit [Server closed connection]
ybogdano has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Windfisch has quit [Server closed connection]
Windfisch has joined #wayland
LaserEyess has joined #wayland
Leopold_ has joined #wayland
marex has quit [Server closed connection]
marex has joined #wayland
any1 has quit [Server closed connection]
columbarius has joined #wayland
any1 has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
kinlo has quit [Server closed connection]
kinlo has joined #wayland
rawoul has quit [Server closed connection]
rawoul has joined #wayland
V has quit [Server closed connection]
V has joined #wayland
caveman has joined #wayland
jadahl has quit [Server closed connection]
jadahl has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
Plagman has quit [Server closed connection]
Plagman has joined #wayland
x2s has quit [Server closed connection]
x2s has joined #wayland
blathijs has quit [Server closed connection]
blathijs has joined #wayland
dos11 has quit [Server closed connection]
dos1 has joined #wayland
emersion has quit [Server closed connection]
emersion has joined #wayland
tzafrir has quit [Server closed connection]
tzafrir has joined #wayland
eroc1990 has quit [Remote host closed the connection]
eroc1990 has joined #wayland
spstarr has quit []
CME has quit [Server closed connection]
CME has joined #wayland
modin has quit [Server closed connection]
modin has joined #wayland
qyliss has quit [Server closed connection]
qyliss has joined #wayland
Serus has quit [Server closed connection]
Serus has joined #wayland
frytaped has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
xantoz has quit [Server closed connection]
xantoz has joined #wayland
ecloud has quit [Server closed connection]
ecloud has joined #wayland
sozuba has joined #wayland
Guest1030 has quit [Server closed connection]
dreda has joined #wayland
dreda is now known as Guest630
ramcq has quit [Server closed connection]
ramcq has joined #wayland
frytaped has quit [Quit: WeeChat 3.6]
frytaped has joined #wayland
frytaped has quit []
frytaped has joined #wayland
frytaped has quit []
frytaped has joined #wayland
frytaped has quit []
zamundaaa has quit [Server closed connection]
ivyl has quit [Server closed connection]
ivyl has joined #wayland
zamundaaa has joined #wayland
kts has joined #wayland
jgrulich has joined #wayland
DPA has quit [Server closed connection]
DPA has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
m5zs7k has quit [Server closed connection]
m5zs7k has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
frytaped has joined #wayland
frytaped is now known as godvino
cool110 has joined #wayland
godvino has quit []
frytaped has joined #wayland
heftig has quit [Server closed connection]
heftig has joined #wayland
hardening has joined #wayland
Company has quit [Quit: Leaving]
junaid has joined #wayland
danvet has joined #wayland
tzimmermann has joined #wayland
mvlad has joined #wayland
jgrulich has quit [Remote host closed the connection]
dcz_ has joined #wayland
jasyuiop[m] has quit [Server closed connection]
jasyuiop[m] has joined #wayland
manuel1985 has joined #wayland
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #wayland
Guest533 has quit [Server closed connection]
enick_737 has joined #wayland
rv1sr has joined #wayland
<Max1>
I have a parent surface with a subsurface. When I press the left mouse button while over the parent surface and then move the mouse (with the button still held) over the subsurface and release the button there, when does the pointer focus leave the parent surface and enter the subsurface?
<Max1>
As soon as the mouse moves over the subsurface, or only when the button is released?
manuel1985 has quit [Ping timeout: 480 seconds]
<pq>
Max1, due to protocol design, it is impossible for wl_pointer focus to enter with buttons down. So focus would switch on all-buttons-up, *if* the sub-surface has input region there.
<Max1>
Thank you!
jgrulich has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
Nico has quit [Server closed connection]
Nico has joined #wayland
<smallville7123>
in wl_event_loop_add_fd why is the fd duplicated?
<smallville7123>
would it be like a file descriptor sephamore?
<smallville7123>
or rather, a reference counted fd?
jgrulich has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<pq>
smallville7123, it's duplicated so that the caller can close its own fd instead of needing to track it.
<pq>
a file descriptor (an int) points to a file description (a kernel structure representing an open file), and file descriptions are reference-counted.
<pq>
A file descriptor holds a reference to the file description.
devilhorns has joined #wayland
<smallville7123>
alright
<smallville7123>
looks like i will need to implement a psuedo-fd struct to make it easier to work with a descriptor on windows/unix platforms :)
<smallville7123>
since both need to be handled very differently
<smallville7123>
(mainly to aid in FD operations such as duping, closing, ect)
<smallville7123>
eg, for eventfd we cannot destinguish between an fd passed via CreateEvent api and an fd passed via the EVENTFD emulation layer when duping
<smallville7123>
mainly because the event loop needs to be passed an opaque fd, so we need to be able to determine an the fd's intended type
<smallville7123>
wait no
<smallville7123>
would it be UB to pass wl_event_loop_add_fd an fd that WAS NOT created by the eventfd api ?
<DemiMarie>
smallville7123: have you considered using ALPC and Windows native `HANDLE`s?
<smallville7123>
like, are wl_event_source_fd and wl_event_source 's fd members expected to ONLY contain descriptors created by eventfd ?
<smallville7123>
or can they contain descriptors created by other api's ?
<kennylevinsen>
I'm curious where you got that idea from
<smallville7123>
what idea?
sozuba has quit [Ping timeout: 480 seconds]
<kennylevinsen>
that wl_event_loop was somehow restricted to certain fd types
<pq>
smallville7123, me and others have said this before: why not just pick a portable event loop library, and delete all the event loop implementation from libwayland?
<smallville7123>
as wl_event_loop_add_fd doesnt explicitly state what api the passed fd must originate from
<smallville7123>
pq: cus doing so would break the libwayland api
<pq>
smallville7123, you will necessarily break it in any case.
<pq>
The only requirement that wl_event_loop_add_fd makes is that the fd must be pollable. I don't know of any fd type that is not pollable.
<smallville7123>
hmmm
<kennylevinsen>
smallville7123: I asked because there is no reference to eventfd anywhere in the eventloop...
<kennylevinsen>
wayland-serverr.c does add an eventfd, but it also adds sockets
<smallville7123>
kennylevinsen: yea
<kennylevinsen>
so I found it to be an odd conclusion to arrive at :)
<pq>
one can even add an epoll fd in order to nest event loops
<smallville7123>
and so we have a problem
<smallville7123>
wl_event_loop_add_fd requires a descriptor, but posix eventfd is unavailable on win32 and must be implemented for behavioural compatibility
<smallville7123>
however wl_event_loop_add_fd duplicates the passed fd, but to dup it correctly the implementation must also duplicate the mutex used to implement blocking
junaid has quit [Ping timeout: 480 seconds]
<smallville7123>
as well as the needed struct members that hold the flag info
<smallville7123>
and the counter
<smallville7123>
but we must ALSO support sockets being passed to wl_event_loop_add_fd
<smallville7123>
both HANDLE and SOCKET's can be detected via handle type ops, but i doubt that a non HANDLE can be detected
<kennylevinsen>
blocking on a mutex to simulate an fd? that already sounds off
<smallville7123>
(eg, a handle type that IS NOT build into the windows kernel)
<smallville7123>
kennylevinsen: blocking is requred when the fd is created without the NONBLOCK flag
<mceier>
just use linux, this will solve all your wayland problems
<smallville7123>
mceier: cant :)
<pq>
you know, people have already solved that problem, and written event loop libraries for you to use so you don't have to go through the same pain.
<smallville7123>
yes but removing wayland's event loop will break the api :)
<pq>
at the very least you could look at how they solved this
<pq>
you are necessarily going to break the api anyway
<kennylevinsen>
your entire problem is that the API doesn't work on windows, and you're gonig to have to make changes such as by replacing fds with handles
<smallville7123>
technically yes since it will require implementation specific GPU buffer code, and maybe WL_SHM api differences?
<kennylevinsen>
so if you already know you're breaking API, why not just use an event library?
<smallville7123>
id rather use wayland's own event api :)
<kennylevinsen>
we're not particularly fond of that API in the first place. The inclusion is arguably a bit of a mistake.
<smallville7123>
heh
<kennylevinsen>
and to be honest, I don't think anyone wants a hacked up version pretending to have the same API on windows when it clearly isn't suitable. :)
<smallville7123>
unless libwayland can officially remove it, i will use it :)
<kennylevinsen>
libwayland has never existed on windows, and clients written for libwayland on linux will not work with the windows version, so you have no reason to concern yourself with that degree of backwards compatibility
<kennylevinsen>
libwayland-windows can just not have that
<smallville7123>
kennylevinsen: heh
<smallville7123>
we will see :)
<kennylevinsen>
if you want to reimplement wl_event_loop for windows, at least do as pq suggests and read other event loop implementations
<smallville7123>
id imagine those would be OS specific
<smallville7123>
i would like to avoid OS specifics wherever possible unless there is no other way :)
<pq>
event loops *are* always OS specific
cvmn has quit [Ping timeout: 480 seconds]
<pq>
that's the reason why you have these problems in the first place
<smallville7123>
or rather, i would like to abstract away the OS specific differences as much as possible
<pq>
that's exactly what those libraries do
<pq>
the portable, multi-OS ones, that is
<emersion>
i've tried to use libev in libwayland, but that doesn't work because it doesn't expose the epoll FD
<emersion>
i wonder if we should add a build option to disable wayland's event loop
<kennylevinsen>
+1 for that, and maybe a soft deprecation notice to suggest that compositors should bring their own loop?
<pq>
emersion, we don't need a build option. We need an API to get the client and socket fds out, instead of being added into the internal event loop.
cvmn has joined #wayland
<emersion>
pq, my goal is to allow e.g. BSD to not build the epoll stuff
<smallville7123>
:)
<pq>
ok, that's a second step
<emersion>
i'm not sure how getting the socket FDs out will help?
<emersion>
i'd rather use wl_client_create(socket_fd)
<pq>
and client fds when they connect?
<smallville7123>
wonder if a windows kernel object could be implemented in user space?
<pq>
smallville7123, then it's not a kernel object, by definition.
<emersion>
and then have wl_display_create_socket() which juts returns the socket FD and does nothing with it, maybe
<emersion>
then it's up to compositors to listen for connections
<emersion>
and call wl_client_create()
<pq>
emersion, right. I believe the current libwayland-sever API is missing a bit or two to make that possible.
<pq>
*server
<smallville7123>
tho i would like to avoid users needing to install a system driver simply to use wayland
<any1>
There's nothing stopping compositors from bringing their own even loop as is. They could just use the epoll fd from libwayland to dispatch libwayland events.
<pq>
emersion, I would approve such plan.
<Max1>
When I press the left mouse button while over a surface and in response to that the client opens an xdg_popup and calls xdg_popup.grab(), what exactly should happen in response to that?
<Max1>
Does it automatically get pointer and keyboard focus, even if the pointer location is not above the popup? What if the user drags the mouse over the popup after the grab() call?
<emersion>
pq, i think we're just missing a helper to create a display socket without adding it to the event loop?
<pq>
any1, but we want to get rid of even that and "manully" watch each client fd indepdendently.
<any1>
Deprecating the event loop would just mean that you'd need to create an "event loop backend" interface for libwayland, which is more of a hassle to implement than to just use the fd.
<emersion>
hm. maybe dispatch client and such
<emersion>
i should just try it and see what's missing
<pq>
emersion, yeah, creating the listening socket and dispatch sound like it. That might be enough.
<smallville7123>
also A fault in a driver brings down the system with a Blue Screen of Death.
<smallville7123>
;-;
<pq>
any1, I think the idea is not have an abstraction of event loops for libwayland-server to use, but simply leave it all for the caller.
<emersion>
indeed
<any1>
That could work.
<emersion>
i wonder what wlroots would do about it
<any1>
What about things such as timers? Are they used inside libwayland?
<pq>
emersion, while at it, maybe have the dispatch to be interruptible, so a compositor can choose to stop serving a client even if it has requests ready?
<emersion>
currently it heavily relies on wl_event_loop
<emersion>
pq, hm, how would the interrupt work?
<pq>
I mean, server a few requests and then move on, even if more requests are ready.
<emersion>
ah, yes
<pq>
*serve
<emersion>
i see
<emersion>
so wl_client_stop_dispatch() inside an event handler for instance…
<emersion>
would be a bit weird, maybe there's a better idea
<pq>
although as MrCooper said, serving requests should be really fast to not need smart scheduling.
<emersion>
we could always have dispatch_single_request
<pq>
...or dispatch one request per call
<emersion>
right
<emersion>
much better
<pq>
any1, I don't recall libwayland-server itself using timers for anything.
<pq>
or anything else, really. It's just the listened sockets and the client sockets.
<any1>
huh, yeah, I just checked
<any1>
It only uses it for monitoring fds
<emersion>
yup
<any1>
Lol, what does it need an event loop for then? :D
<pq>
it needs to watch multiple fds
<pq>
*needs* to
<pq>
err... "needs" to
<any1>
Yeah, but I mean, it doesn't need it's own implementation, like you guys are saying
<pq>
correct
<pq>
it's a historical artifact
<pq>
from before weston was split out from wayland
<pq>
krh left a bunch of stuff in libwayland-server that surely every compositor is going to need, like the event loop and wl_shm implementation
<pq>
Many years later, compositors still do need these, but having libwayland-server provide these is a bit of a hindrance.
<pq>
A problem of sharing too much code, or in an awkward way.
fmuellner has joined #wayland
<Max1>
(reposting my question from above because I think it got lost in the other discussion)
<Max1>
When I press the left mouse button while over a surface and in response to that the client opens an xdg_popup and calls xdg_popup.grab(), what exactly should happen in response to that?
<Max1>
Does it automatically get pointer and keyboard focus, even if the pointer location is not above the popup? What if the user drags the mouse over the popup after the grab() call?
Szadek has joined #wayland
jgrulich has joined #wayland
frytaped is now known as Guest679
enick_737 is now known as frytaped
frytaped is now known as go4godvin
Guest679 has quit []
frytaped has joined #wayland
frytaped is now known as Guest681
Guest681 is now known as frytaped
frytaped has quit []
frytaped has joined #wayland
jgrulich has quit [Remote host closed the connection]
tomke has joined #wayland
<zamundaaa[m]>
Max: it should get keyboard focus, but afaik pointer and touch should be handled like without the grab
<tomke>
Hi
<tomke>
I have a quiestion regarding the alpha channel handling in EGL_WL_bind_wayland_display
<Max1>
zamundaaa: Thank you, that is my interpretation of the spec as well ("During a popup grab, the client owning the grab will receive pointer and touch events for all their surfaces as normal (similar to an "owner-events" grab in X11 parlance), while the top most grabbing popup will always have keyboard focus.")
<tomke>
EGL_TEXTURE_RGB
<tomke>
One plane, samples RGB from the texture to rgb in the shader. Alpha channel is not valid.
<tomke>
and yet the GL rendere uses RGBA shader that does read the alpha channel
<tomke>
is this a bug?
<tomke>
or is it intentional, as in "invalid alpha" is suppsed to give alpha=1 in the shader?
<tomke>
There's already RGBX shader variant that assumes constant alpha=1 instead of reading it from the sampler,
<tomke>
which might be a tad faster for EGL_TEXTURE_RGB
<pq>
tomke, are you asking about Weston?
<tomke>
yes
<pq>
when pixel format is XRGB, GL sampling alpha will just get 1.0, the GL implementation smashes that.
<tomke>
I had a request to implement Vulkan interop as ARGB with an external "opaque" flag
caveman has joined #wayland
<pq>
the RGBX shader variant is needed when the pixel format is ARGB but we know that the A channel may be bogus. Xwayland has had use for this.
cvmn has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
<tomke>
that's exactly what happens if I keep Vuklan format intact (Vulkan doesn't do RGBX) and send Vulkan opaque swapchain presentation as a separate flag
<pq>
RGBX shader variant seems to be used also for wl_shm content with an XRGB pixel format type, maybe because uploading a texture we cannot tell GL to ignore the X channel
<tomke>
I have a patch that picks RGBX variant for EGL_TEXTURE_RGB, it's fairly trivial
<tomke>
would you like me to do a merge request?
<pq>
sorry, I still didn't understand what you're talking about.
<tomke>
Oh, sorry
<pq>
looks like EGL_TEXTURE_RGB et al. are only used with EGL_WL_bind_wayland_display. Can the graphics stack not use zwp_linux_dmabuf_v1 instead?
<pq>
it would be weird if EGL tells us we don't have alpha channel and then using it as a texture would *also* require us to manually smash alpha to 1.0. Why wouldn't GL do that already?
<tomke>
the dmabuf is the next thing on my list :)
<tomke>
as for the alpha, the extension wording is "Alpha channel is not valid."
<pq>
...which should cause GL to return 1.0 alpha samples, right?
<tomke>
that's my gut feeling, but a coleague of mine suggest that it means that the alpha channel may contain bogus data
<pq>
same thing: don't read it
<tomke>
fair enough
kts has joined #wayland
<pq>
to me, the difference between EGL_TEXTURE_RGB and EGL_TEXTURE_RGBA is that _RGB is guaranteed opaque.
<tomke>
thanks
<pq>
I can see that alternative interpretation, but it would be odd to change the behavior after all these years.
<pq>
particularly when such manual alpha-smashing is not needed when you import a dmabuf with an opaque pixel format
<tomke>
that's exactly what I responend to the suggestion, but I promosed that I;'ll ask
<pq>
heh :-)
<pq>
the thing with EGL_WL_bind_wayland_display is that the actual buffer metadata negotiation is hidden in the EGL implementation, so it really should get everything right as it can communicate whatever it wants.
<tomke>
exactly, my test hack was using RGBA internal format but reporting EGL_TEXTURE_RGB if Vulkan swapchain was supposed to be presented opaque, and that didn't work
jmdaemon has quit [Ping timeout: 480 seconds]
<tomke>
that how the shader was actually geting alpha chanel data instead of 1
<tomke>
it's the alternative interpretation "no valid" alpha channel which I didn't quite like
<x2s>
Is there an option for weston to always activate screen-share and not just by pressing Ctrl+Alt+s?
<pq>
x2s, yes, in weston.ini
jgrulich has quit [Remote host closed the connection]
<x2s>
oh, I'm blind... that was the "here be dragons" option
<pq>
hehe, well, the same warnings apply in any case
<x2s>
works in principle, but I don't like that my rdp client doesn't change its resolution to fit the display. Also I have to get rid of the mouse cursor
cvmn has joined #wayland
caveman has quit [Remote host closed the connection]
gschwind has joined #wayland
Leopold_ has quit [Remote host closed the connection]