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
<tommybomb>
looks good
molinari has quit [Ping timeout: 480 seconds]
amnesia163 has joined #wayland
eroc1990 has quit [Remote host closed the connection]
eroc1990 has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
<marex>
this is probably not the best place to ask, but ...
<marex>
[328:328:0221/011510.720137:ERROR:wayland_event_watcher.cc(38)] libwayland: xdg_wm_base@23: error 4: xdg_surface geometry (500 x 272) is larger than the configured fullscreen state (480 x 272)
<marex>
I get this ^ when I start chromium 109 on stm32mp15xx board with 480x272 panel
<marex>
i.e. chromium --start-fullscreen --kiosk
paulk-bis has joined #wayland
paulk has quit [Read error: Connection reset by peer]
<bl4ckb0ne>
looks like a chromium bug
<soreau>
but it works on wlroots wayland backend if I set that 'mode' and use the same options..
<marex>
I have seen this with gstreamer before too, I need to recheck that one
<soreau>
I get the same error from chromium when I try weston wayland backend with that resolution
<marex>
scratch that, gstreamer seems just fine on this one
<soreau>
but it works with wayfire
<marex>
btw weston 10.0.2
<marex>
soreau: it works fine with weston with other resolution panels too
<marex>
I wonder if chromium is doing some weird rounding
<soreau>
idk why weston thinks this is an error though.. what if this is the client surface minimum size? or the min size was larger than the output resolution in some dimension?
<marex>
if I stick a breakpoint into libweston/desktop/xdg-shell.c line 770 , and run BT once that triggers , I should get a backtrace all the way into chromium, right ?
<soreau>
no?
<marex>
no ... I won't, coz chromium isnt linked against this
<marex>
51 static constexpr int kMainBrowserContentsMinimumWidth = 500;
<marex>
dang
nerdopolis has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
i509vcb has joined #wayland
<marex>
so yeah, that one is the change ... now how to upstream that into chromium, urgh
<soreau>
there's even some options you think that might help, like --window-size or --ozone-override-screen-size, but none of them affect the minimum size apparently
naveenk2 has quit [Ping timeout: 480 seconds]
<soreau>
and if you want to patch chromium, maybe those options or some other new option should be able to override the default
<marex>
soreau: I had a look at the contribution guidelines, ugh ... I just sent email to the commit authors with a oneliner patch, let's see what happens
abeltramo has quit [Read error: Connection reset by peer]
abeltramo has joined #wayland
naveenk2 has joined #wayland
slattann has joined #wayland
naveenk21 has joined #wayland
naveenk22 has joined #wayland
naveenk23 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk21 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
naveenk22 has quit [Ping timeout: 480 seconds]
naveenk23 has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
eroc1990 is now known as Guest5461
eroc1990 has joined #wayland
Guest5461 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
Company has joined #wayland
kts has quit [Quit: Konversation terminated!]
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
ngortheone has quit [Remote host closed the connection]
gspbirel56 has quit []
gspbirel56 has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
junaid has quit [Remote host closed the connection]
<kennylevinsen>
soreau, marex: when the window state is fullscreen: "The window geometry specified in the configure event is a maximum; the client cannot resize beyond it."
<soreau>
but where is the part that says set_min_size() is meaningless when fullscreen
<kennylevinsen>
in set_min_size: "The compositor can use this information to allow or disallow different states like maximize or fullscreen and draw accurate animations.", but also: "The client should not rely on the compositor to obey the minimum size."
<kennylevinsen>
so the compositor *might* just block fullscreen altogether, or not and request a size smaller than min which must be obeyed. Either is fine by the protocol it seems.
dcz_ has joined #wayland
rasterman has joined #wayland
sozuba has joined #wayland
naveenk2 has joined #wayland
molinari has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
<pq>
soreau, weston thinks it is an error, because the protocol spec defines it to be an error.
naveenk2 has quit [Ping timeout: 480 seconds]
<pq>
yeah, Weston could just refuse the fullscreening request completely if min_size indicates the client cannot do it. Would that be better?
<pq>
I bet then naive clients will get confused when they didn't get to be fullscreen like they asked... but that's again a client bug
naveenk2 has joined #wayland
amnesia163 has quit [Remote host closed the connection]
junaid has joined #wayland
fmuellner has joined #wayland
Leopold_ has quit [Remote host closed the connection]
<soreau>
it would make more sense if the compositor would scale the image down, preserving aspect, center and apply black borders if needed, in the case that it is larger than the output geometry
<soreau>
it's nice that there is the freedom to implement what you want without regard for the written spec..
<pq>
soreau, but then the window becomes unreadable, if eve the client is unable to make it any smaller.
<pq>
*even
Leopold_ has joined #wayland
<pq>
soreau, it is very much regarding the written spec.
<pq>
compositor that do not send the error are not implementing the protocol as spec'd
<soreau>
indeed
<soreau>
also, it's nice to have fullscreen semi-transparent terminal with blurred desktop contents blended
<soreau>
instead of boring black
<pq>
maximized, sure
manuel1985 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
Leopold___ has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
d42 has joined #wayland
julio7359 has joined #wayland
pochu has joined #wayland
vyryls has joined #wayland
naveenk2 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
ahartmetz has joined #wayland
mvlad has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
<pq>
swick[m], I tought of adding rendering intents to the protocol. Technically it looks like it should be defined independently for each image description factory, but that's also very redundant at first. What do you think?
bodiccea_ has quit [Read error: Connection reset by peer]
<pq>
oh, we already have rendering intents, but not inside image description - makes sense
Leopold___ has quit [Read error: Connection reset by peer]
Leopold_ has joined #wayland
MrCooper has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
naveenk2 has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
junaid has joined #wayland
ahartmetz has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
<swick[m]>
pq: I'm not sure about rendering intents outside ICC
<pq>
swick[m], you mean everything else would be random magic perceptual?
<swick[m]>
jup
<swick[m]>
but I also started to wonder about separating the video signal description from the parametric description
<pq>
with the exception of a client using an output image description directly
<pq>
what do you mean?
<swick[m]>
if the image description of the output and input is the same there is no conversion required and thus the rendering intent is meaningless
<swick[m]>
urgh, wait, I got it wrong in my head again
<pq>
yes, I've been thinking about writing down that if a client uses the output image description directly on a surface, then rendering that surface on that output will be "no conversion".
<pq>
so overrride render intent, but on that output only
<pq>
and only as long as the image description is current on that output
<swick[m]>
so an image description tells us the colorimetry for a specific output in a specific viewing environment. no matter how we get that colorimetry (ICC or params), we need a rendering intent when we want to convert that to the image description of the output.
<swick[m]>
so I guess it makes sense to keep it outside of the image description
kts has joined #wayland
<swick[m]>
but also supporting different rendering intents requires specific support for them in the compositor
<swick[m]>
probably makes sense to make them all optional except for perceptual
junaid has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
gildekel has quit [Quit: Connection closed for inactivity]
sozuba has quit [Quit: sozuba]
julio7359 has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit []
rasterman has quit [Quit: Gettin' stinky!]
junaid has joined #wayland
Paul33 has joined #wayland
sav10 has joined #wayland
sav10 has quit []
junaid has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Paul33_ has joined #wayland
Paul33 has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
junaid_ has joined #wayland
jmdaemon has joined #wayland
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
tzimmermann has quit [Quit: Leaving]
dcz_ has quit [Ping timeout: 480 seconds]
Paul33_ has quit []
Moprius has joined #wayland
julio7359 has joined #wayland
agd5f_ has quit []
agd5f has joined #wayland
rv1sr has quit []
junaid_ has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
mvlad has quit [Remote host closed the connection]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
i509vcb has joined #wayland
<tommybomb>
Hi, I wanted to know why most inputs are put through the wayland protocol, but the gamepad (controller) is not. Any info is welcomed, thanks.