ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Guest13693 has quit [Remote host closed the connection]
cool110 has joined #wayland
Leopold_ has quit [Remote host closed the connection]
cool110 is now known as Guest14133
pbsds is now known as Guest14138
Guest14138 has quit [Read error: Connection reset by peer]
pbsds has joined #wayland
Guest14133 has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
glennk has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
garnacho has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
I wonder if it's possible to have more than one xdg_popup per wl_surface
<orowith2os[m]>
not in a chain, but a wl_surface actually has two separate xdg_popups, both active
systwi has quit [Remote host closed the connection]
Leopold_ has joined #wayland
crazybyte0 has quit [Read error: Connection reset by peer]
crazybyte0 has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest14148
Leopold__ has joined #wayland
Leopold__ has quit [Remote host closed the connection]
Leopold_ has quit [Ping timeout: 480 seconds]
Guest14148 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest14150
<danieldg>
orowith2os[m]: consider multi-seat, with two cursors over two elements both getting a tooltip popup. Or, both touch and mouse interactions generating popups.
<orowith2os[m]>
I'm guessing that's a yes, then
<danieldg>
I'd check to see if you can make it happen on existing compositors too
nerdopolis has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
eeyue has quit [Read error: Connection reset by peer]
<Eighth_Doctor>
I just filed the request for having weston respond to locale1 for keyboard settings, and I was wondering if anyone would be able to take a look into it sooner rather than later
<Eighth_Doctor>
for the anaconda case, most of the things I don't need to worry about right now... but responding to locale1 for keyboard configuration would cover the basic needs
<pq>
I would think that dynamic reconfiguration should also be persistent, and not like xrandr etc making the next start-up a mess.
<Eighth_Doctor>
yes, ideally it would trigger writing to weston.ini
<Eighth_Doctor>
but I don't think anything in weston does that
<Eighth_Doctor>
in that respect, it follows the xserver model in only reading persistent config
<Eighth_Doctor>
it does, however, lack a weston.ini.d config thing
<pq>
We barely have NIH'd code to read weston.ini, extending that is probably not the best idea. Personally I'd like to see Weston using some library for this that does it all.
<Eighth_Doctor>
yeah
<pq>
You wouldn't happen to have any suggestions for such lib?
<Eighth_Doctor>
I might actually
<Eighth_Doctor>
pq: three options I can think of: libeconf, libconfuse, and libconfig
<pq>
cool, I'm trying to find the old Weston issue to list these in, I thought there was one...
<Eighth_Doctor>
I would probably go with inih over iniparser
<Eighth_Doctor>
since inih more closely matches Weston's existing ini parsing
<Eighth_Doctor>
though if I'm being honest, if we could, I'd change to TOML instead
<pq>
I think we could also do something completely different than current weston.ini, if it's attractive enough.
<Eighth_Doctor>
there are a lot more implementations and it's standardized in a way that ini is not
<soreau>
pq: that route probably looks a lot like kanshi with weston supporting wlr-output-management protocol
<soreau>
then you'd get wlr-randr support for free too
<pq>
maybe that means we need to write a second Weston frontend, but that would be a good long-term exercise anyway, because people are supposed to be able to do that, and right now it's practically intractable.
<pq>
frontend is the component that defines e.g. configuration formats and policies
<Eighth_Doctor>
soreau: funnily enough, zamundaaa and I were talking about that in the context of kwin... it seems kde's dpms protocol is more powerful, and it might be worth making an ext- protocol formally to supersede both wlr-output-management and kde-dpms that compositors can implement
<Eighth_Doctor>
because the situation sucks as it currently stands
<emersion>
how more powerful?
<emersion>
wlr-output-management doesn't do "DPMS"
<emersion>
("DPMS" is a legacy name for power management)
eeyue has joined #wayland
<emersion>
wlr-output-power-management does "DPMS"
<zamundaaa[m]>
The dpms protocol only differs from the wlroots one in that it has an event for whether or not dpms is supported
<emersion>
when is that not supported?
<zamundaaa[m]>
In nested sessions
<emersion>
wlroots unmaps the surface in that case
<zamundaaa[m]>
And in general, virtual outputs
<emersion>
it would be fine to do nothing as well
<emersion>
i think it makes sense to allow "turning off" a virtual output
<soreau>
Eighth_Doctor: it won't happen if no one moves it forward
<zamundaaa[m]>
Fwiw I don't see KWin adopting the wlroots or an ext output management protocol. At least not as a replacement for the kde proto
<soreau>
that's their problem though
<emersion>
zamundaaa[m]: last time i looked at it i thought the KDE one could sit on top of the wlr one?
<emersion>
that would be nice
<emersion>
i've tried hard to make the protocol externally-extensible when designing the wlr proto
<Eighth_Doctor>
the fragmentation on these basic protocols is extremely irritating because all the little utilities with incompatibilities or unknown uselenessness makes things very hard
<Eighth_Doctor>
*uselessness even
<zamundaaa[m]>
It would be possible, but possibly more effort than supporting two entire protocols. KWin's internal architecture is almost entirely ignorant of the underlying protocol
<emersion>
;_;
<zamundaaa[m]>
I'll give implementing it a try when I have time
<emersion>
let me know if the wlr proto is lacking in some way
<Eighth_Doctor>
maybe I should just take the existing one and submit it :/
Leopold has joined #wayland
<Eighth_Doctor>
then I can drop the dumb "unstable" name that exists
<emersion>
yeah, but i don't think it's a good idea to clutter ext- with protos that may be specific to a single compositor
<Eighth_Doctor>
yes, but who would do that?
<Eighth_Doctor>
right now, the current situation is that it's too hard to get an xdg protocol, and there are effectively no avenues for protocols that are adopted by some and ignored by others
Guest14150 has quit [Remote host closed the connection]
cool110 has joined #wayland
<wlb>
wayland-protocols Merge request !192 closed (governance: relax ACK requirements for the ext namespace)
cool110 is now known as Guest14185
<emersion>
ext is that avenue
<soreau>
the more protocols that get upstreamed to w-p, the more chance that the ecosystem utilities as a whole will start cooperating better together
<Eighth_Doctor>
emersion: not right now, even ext protocols are stuck
<emersion>
some are stuck because of disagreements between compositors
<emersion>
some are stuck because only a single compositor cares
<emersion>
either way, the solution isn't that MR to relax rules
<Eighth_Doctor>
true
<Eighth_Doctor>
the solution needs to be that a single NACK can't kill everything
<emersion>
nobody has been NACK'ing
<emersion>
it's just unresolved discussions, or missing ACKs
<emersion>
(ext can't be NACK'ed anyways)
<Eighth_Doctor>
well then, I guess I'll try with output-management then
<Eighth_Doctor>
we'll see how that goes, watching ximion's adventure though was somewhat disheartening
<emersion>
but the latter probably not a good idea
<emersion>
still unsure how these mode aspect ratio flags should get exposed to users
jkl has joined #wayland
<Eighth_Doctor>
hmm, that would be needed for Weston too
<Eighth_Doctor>
since it exposes configuring the aspect ratio
<emersion>
i think the right thing to do is to disregard modes with flags, and let the compositor set it depending on fullscreen surface aspect ratio
<emersion>
and/or a dedicated aspect ratio protocol
<emersion>
but that needs a modeset
<Eighth_Doctor>
I am not sure why aspect ratio is a settable thing
<emersion>
sigh
<Eighth_Doctor>
it's usually derived from the WxH, no?
<Eighth_Doctor>
or am I missing something here?
kts has joined #wayland
<emersion>
the EDID allows setting a picture aspect ratio different from mode aspect ratio
<Eighth_Doctor>
O.o
<emersion>
well, not EDID, rather the HDMI InfoFrames and such
<Eighth_Doctor>
okay I guess
<Eighth_Doctor>
is that what makes "black bars"?
<pq>
non-square pixels are a thing
<Eighth_Doctor>
oh right, that
<Eighth_Doctor>
I should have remembered that, since I know of OLED panels like that
<emersion>
if you watch a 16:9 movie on a 4:3 screen, you'd use a 4:3 mode with a 16:9 picture aspect ratio
<emersion>
pq, i think that's unrelated though?
<pq>
picture aspect ratio is about non-square pixels, AFAIK
<emersion>
vsyrjala: ^ do you know details?
privacy has quit [Quit: Leaving]
<emersion>
pq, that doesn't match my recollection of the EDID spec
<emersion>
CTA*
<emersion>
but maybe i'm misremembering
<pq>
I can't think of what else it could be, if not for non-square pixels. Otherwise there would be no need to send anything else than width and height.
<pq>
emersion, are those about CEA modes? VIC? They don't look familiar.
<emersion>
this is the definition of picture aspect ratio
<pq>
I'm thinking more of DRM_CLIENT_CAP_ASPECT_RATIO
Leopold has quit [Remote host closed the connection]
<emersion>
that's the same thing
<emersion>
this cap enables the picture aspect ratio flags in mode
<emersion>
i kind of wish ATOMIC didn't implicitly enabled this cap…
mtretter has joined #wayland
shoragan has joined #wayland
<pq>
emersion, if look at CTA-861-H, section 4.1 Aspect Ratio, there is a table with lots of modes with Pixel Aspect Ratio other than 1:1.
<emersion>
right, but that's not the picture aspect ratio flag
<pq>
how is it not?
<emersion>
picture aspect ratio ≠ pixel aspect ratio
<emersion>
well, it's just two different concepts?
<pq>
looking at the table, pixel aspect ratio is derived from resolution and picture aspect ratio.
<pq>
IOW, picture aspect ratio can be chosen to result in either square of non-square pixels, depending on each mode. Some modes do not even have a square pixel variant.
<pq>
*or
<pq>
this is the VIC list
<pq>
picture aspect ratio flags in KMS are just used for choosing the right VIC, because resolution alone is not enough
<pq>
and there's a ton of VICs with non-square pixels - like there are MPEG etc. videos as well, I believe
<pq>
FWIW, Wayland clients can provide non-square pixels to the compositor using wp_viewport, but we do not have a way to tell clients what would match the display.
<zxrom>
My two different old Microsoft IntelliPoint 3 and 4 mice are behaving strangely. More than a year ago, the scroll wheel started working spontaneously. Perhaps the new mouse input processing module has removed protection against this behavior of these mice? I have already disassembled and cleaned everything from dust. It did not help. Who has a similar problem? Anyone have any ideas?
<bl4ckb0ne>
there has been a change recently regarding scrolling wheel
<zxrom>
Recently is it a year and a half or two years ago? It seems there was another input module before.
<zxrom>
XOrg, LXDE,Openbox
<zxrom>
libinput
<zxrom>
ArchLinux
privacy has joined #wayland
<zxrom>
This bug shook my nerves! This works on taskbar buttons often. I usually leave the mouse pointer there.
<zxrom>
:D
<zxrom>
bl4ckb0ne, Perhaps from high resolution mouse wheel scrolling to return the old behavior?
* bl4ckb0ne
shrugs
glennk has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
cant say much about x11 DE
<zxrom>
Is it possible to disable high resolution mouse wheel scrolling to return the old behavior?*
<zxrom>
I wonder if this module misses real mouse wheel triggers or erroneously generates them internally due to some algorithms? I have not seen this behavior of the wheel in Windows.
kts has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
tzimmermann has quit [Quit: Leaving]
Brainium has joined #wayland
zxrom has quit [Quit: Leaving]
garnacho has joined #wayland
rgallaispou has left #wayland [#wayland]
glennk has joined #wayland
rv1sr has joined #wayland
occivink has quit [Quit: WeeChat 3.7.1]
mclasen has quit [Ping timeout: 480 seconds]
occivink has joined #wayland
<vyivel>
from compositor side, is there a way to stop new clients from connecting?
<kchibisov>
Instantly kill them?
<vyivel>
that's what i'm doing right now but maybe there's a better way
<kchibisov>
It boils down to unix socket APIs.
<vyivel>
right
<emersion>
you can close the listener
<emersion>
but i don't think libwayland lets you access it
<emersion>
we have a function to disconnect all clients
<kchibisov>
they want a way to not add new clients, but keep the already connected ones, I think.
<vyivel>
the context is i'm doing some cleaning up between wl_display_destroy_clients() and wl_display_destroy() which involves dispatching events though now i'm realising i don't really need to do that
mclasen has joined #wayland
<vyivel>
nope, still do
<vyivel>
whatever, client_created listener with wl_client_destroy() works
privacy has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Quit: Leaving]
eeyue has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest14209
Guest14193 has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
narodnik has joined #wayland
qyliss has quit [Quit: bye]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
rv1sr has quit []
eeyue has joined #wayland
eeyue has quit [Ping timeout: 480 seconds]
eeyue has joined #wayland
eeyue has quit [Ping timeout: 480 seconds]
mohit8158226 has quit [Quit: mohit8158226]
mohit8158226 has joined #wayland
qyliss has joined #wayland
eeyue has joined #wayland
qaqland_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
qaqland has quit [Ping timeout: 480 seconds]
qaqland_ is now known as qaqland
rasterman has quit [Quit: Gettin' stinky!]
eeyue has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
Leopold_ has quit [Remote host closed the connection]
columbarius has joined #wayland
Guest14209 has quit [Remote host closed the connection]
co1umbarius has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest14223
fmuellner has joined #wayland
that_guy has quit [Quit: I'M OUT]
Guest14223 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest14229
that_guy has joined #wayland
that_guy has quit [Ping timeout: 480 seconds]
that_guy has joined #wayland
mvlad has quit [Remote host closed the connection]