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
TattooedTech has joined #wayland
st3r4g has quit [Quit: おやすみ]
Seirdy has quit []
Seirdy has joined #wayland
Seirdy has quit []
columbarius has joined #wayland
Seirdy has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
CodeSpelunker has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
CodeSpelunker has quit [Remote host closed the connection]
CodeSpelunker has joined #wayland
boistordu_ex has quit [Ping timeout: 480 seconds]
<maxzor>
Hello
<maxzor>
Can any wayland client implementation talk to any wayland compositor implementation?
c7s has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
<pq>
soreau, graceful errors (ones that do not disconnect the client, but make the client try something else instead of silently malfunctioning) requires explicit support in the relevant protocol extension.
<pq>
some particular things do have it
<daniels>
^ e.g. zwp_linux_dmabuf_params_v1
rasterman has joined #wayland
<mort_>
Is it possible to disable vsync in weston? I can't find any docs for it, the only place vsync seems to be mentioned is the "+vsync" in the example modeline but weston doesn't seem to actually disable vsync when you replace it with "-vsync"
dcz_ has joined #wayland
<daniels>
mort_: no, Weston will only ever paint once per vertical refresh
<mort_>
annoying
<daniels>
mort_: if you want client buffers to tear then support for that is WIP, but there's no way to just freeform paint everything all the time with no synchronisation
<daniels>
I don't know of any compositor which just smashes content into the front buffer with no synchronisation
<daniels>
why do you want that?
<mort_>
currently, to test what the GPU is capable of
<daniels>
you don't need either Weston or the GPU for that, you can just use something like glmark2 rendering to an FBO
<mort_>
I also have an issue where every application in weston seems to be limited to 30 FPS
<daniels>
for that, try putting [core]\nrepaint-window=15 into your weston.ini
<mort_>
I don't have glmark2 on this embedded system and getting it compiled for it would probably be a ton of work if it's at all possible
<mort_>
huh, repaint-window=15 works
<mort_>
why wouldn't weston default to that when the modeline specifies a refresh rate of 60
<daniels>
which embedded system is it?
<mort_>
a rockchip px30
<daniels>
ah
<mort_>
on a custom board and such, I can't really refer you to an sbc
<daniels>
if you're using Rockchip's downstream kernel, then their KMS driver is pretty horrendously broken
<mort_>
nice
<daniels>
repaint-window=15 isn't globally needed, it's just something that works around terrible platforms
<daniels>
making it dynamically adjust is on the wishlist
<mort_>
not terribly impressed with rockchip so far tbh, they only support 4.4 and have a ton of out-of-tree patches it seems
<daniels>
porting whatever you need to mainline is far less work than trying to unbreak their vendor tree
<mort_>
probably not
<daniels>
ok
<mort_>
maybe if linux had a stable driver API and a stable way to describe hardware so we could just use the same drivers and dts and carry it forwards
<mort_>
but I know we're never getting that so it's moot
<daniels>
...
<daniels>
I mean currently you're frozen in time against an ancient Rockchip BSP
<mort_>
yes
<mort_>
well
<mort_>
the latest rockchip BSP
<daniels>
if you want to be frozen in time with a less broken base, you could freeze your random out-of-tree drivers against mainline, which is less broken
<daniels>
but that's your choice, I'm not going to argue with you, enjoy
<mort_>
getting a random out-of-tree driver from 4.4 to 5.14 or whatever is the problem though, right
<mort_>
I don't disagree that things would be much better if we were on mainline
<mort_>
but I know from experience that upgrading between kernel versions is a huuuge undertaking
<mort_>
and presumably it's even bigger when going from a heavily patched vendor kernel to mainline
<mort_>
anyways, the repaint-window=15 workaround works for now, thanks. I may experiment with mainline if only to figure out just how much is broken
DavidRedondo[m] has joined #wayland
sstiller has quit [Quit: Leaving]
flacks has quit [Quit: Quitter]
flacks has joined #wayland
st3r4g has joined #wayland
mbalmer_ has joined #wayland
mbalmer has quit [Read error: Connection reset by peer]
maxzor has joined #wayland
TattooedTech has quit [Quit: Leaving]
immibis has quit [Remote host closed the connection]
<mort_>
fuuuuuuuck wlroots requires a bleeding edge meson
gryffus has quit []
<mort_>
why does wlroots have to make everything so complicated
<emersion>
wlroots master is the bleeding edge, thus it also requires the bleeding edge
<mort_>
wlroots 0.13 isn't bleeding edge
<mort_>
I'll just use wlroots 0.12
<emersion>
wlroots 0.13 requires the meson version that was published when 0.13 was released
<mort_>
why?
<mort_>
wasn't meson good enough before
<Emantor>
because it uses newer meson features.
<Emantor>
Every meson bump within wlroots is because the newer feature is only available in an up-to-date meson
<emersion>
if you use wlroots released on $date, it'll require deps from $date
<mort_>
I'll just use wlroots 0.12, it's fine
<LaserEyess>
you can install the latest meson with pip if you so need, wlroots has rapid development and many changes between versions
<LaserEyess>
you're not doing yourself any favors by using a version that's even only 1 year old
<mort_>
can't install the latest meson with pip in yocto
<emersion>
send yocto a patch to upgrade meson
<mort_>
maybe meson isn't ready for actual serious use if it's upgraded so frequently that one can't use old versions
<Emantor>
Current yocto has current meson. But the downstream rockchip stuff is stuck in the ancient past.
<Emantor>
Stop blaming projects and start blaming vendors.
<emersion>
ah, vendor yocto
<mort_>
I mean
<mort_>
it's using gatesgarth
<mort_>
that's pretty new
<emersion>
sorry, i have absolutely no sympathy for vendored stuff
<mort_>
I'd prefer if it was on dunfell since that's an LTS but that's fine
<Emantor>
gatesgarth is two releases old by now and no longer supported.
<mort_>
yeah, hence why I'd prefer dunfell
<Emantor>
dunfell LTS will turn out to be even worse.
<mort_>
it's supported
<mort_>
but as I said, I'll just use wlroots 0.12, it's fine
<Emantor>
"Supported" until you suddenly realize that you have to incorporate changes from the next 4 yocto releases to get to the next LTS release.
<mort_>
I didn't say anything is easy
st3r4g has joined #wayland
maxzor has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
<soreau>
pq: ok thanks
zebrag has joined #wayland
spstarr has joined #wayland
arin0v has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
arin0v has quit [Read error: No route to host]
arinov has joined #wayland
<arinov>
didnt work
<arinov>
oops
<arinov>
wrong buffer
arinov has quit []
arinov has joined #wayland
arinov has quit [Quit: WeeChat 3.3]
arinov has joined #wayland
cvmn has joined #wayland
<maxzor>
I don't see xdg_shell in the list of globals of my mutter : does that mean that my compositor does not support server-side window decorations and handling, and that I have to write my own decorations? http://ix.io/3GHv
johnsmith_ has quit []
<st3r4g>
maxzor: xdg_shell is xdg_wm_base, but that's not about server-side decorations
<st3r4g>
which would be xdg-decoration, which mutter doesn't support
<st3r4g>
zxdg_shell_v6 has become xdg_wm_base, but mutter apparently has not removed it yet
fmuellner has quit [Ping timeout: 480 seconds]
st3r4g has quit [Quit: おやすみ]
arinov has quit [Ping timeout: 480 seconds]
bango has joined #wayland
bango has quit []
bango has joined #wayland
bango has quit []
bango has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
bango has quit []
Decius has joined #wayland
cvmn has joined #wayland
leon-p has joined #wayland
boistordu has joined #wayland
tzimmermann has quit [Quit: Leaving]
TattooedTech has joined #wayland
maxzor has quit [Remote host closed the connection]
st3r4g has joined #wayland
and3rson has joined #wayland
maxzor has joined #wayland
<and3rson>
Sorry if this is the wrong channel, but anyone has any idea why the hell is Spotify (when running with `--enable-features=UseOzonePlatform --ozone-platform=wayland --disable-gpu`) showing an unnamed black window over its main window? It's almost working great, but this window just messes everything up. This window has no title and no app_id. Is this some electron quirk?
<and3rson>
No issues with mattermost or slack thought
<and3rson>
That window is an X window, btw
<maxzor>
no clue here. why do you like the native app over the browser? curious never really felt the need on deezer here
st3r4g has quit [Quit: おやすみ]
fmuellner has joined #wayland
maxzor has quit [Quit: compiuter crash]
danvet has quit [Ping timeout: 480 seconds]
Decius has quit [Remote host closed the connection]
maxzor has joined #wayland
pnowack has quit [Quit: pnowack]
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
maxzor has quit [Remote host closed the connection]
hardening has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
immibis has quit [Remote host closed the connection]
immibis has joined #wayland
vhns has quit [Quit: leaving]
maxzor has quit [Ping timeout: 480 seconds]
cvmn has quit [Quit: cvmn]
spstarr has quit [Remote host closed the connection]