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
duxsco has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
shankaru has joined #wayland
saumon has quit [Ping timeout: 480 seconds]
saumon has joined #wayland
shankaru has quit []
naveenk2 has joined #wayland
shankaru has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
mvlad has joined #wayland
hergertme has quit [Remote host closed the connection]
hergertme has joined #wayland
naveenk2 has quit [Read error: Connection reset by peer]
rpigott has quit [Remote host closed the connection]
rpigott has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
radu242 has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
bodiccea has quit [Remote host closed the connection]
romangg has quit []
bodiccea has joined #wayland
andyrtr has quit [Remote host closed the connection]
CME has quit []
CME has joined #wayland
rv1sr has quit [Remote host closed the connection]
andyrtr_ has joined #wayland
andyrtr_ is now known as andyrtr
jmdaemon has quit [Ping timeout: 480 seconds]
romangg has joined #wayland
lxsameer4 has joined #wayland
tzimmermann has joined #wayland
duxsco has joined #wayland
peeterm has quit []
peeterm has joined #wayland
<Lightsword>
anyone know what might be causing a "BUG: layer_list is not empty after shutdown. Calls to weston_layer_fini() are missing somwhere." error in weston 10.0.0?
<emersion>
zamundaaa: hm, i'm confused regarding the fractional scale discussion
<emersion>
subsurface positions are always integers in logical coords
<emersion>
so your issue is that there are off-by-one errors for subsurface positions sometimes?
<mvlad>
Lightsword, we failed to destroy weston_views upon shutting down. What shell are you using?
<emersion>
but isn't that an issue with existing fractional scaling implementations in compositors already?
<Lightsword>
mvlad shell=desktop-shell.so
<mvlad>
Lightsword, are you using xwayland by any chance? Or what applications are still running while closing it?
<mvlad>
Lightsword, oh so weston it's not starting at all?
<mvlad>
Lightsword, was under the impression that weston started, you started cog, then attempt to close/shutdown weston and was seeing that.
<Lightsword>
mvlad, doesn't seem to be, seems a bad transform value causing early shutdown or something, if I remove the transform value it starts but no video output
<Lightsword>
there's one monitor connected to "DVI-D-1" FYI
<mvlad>
Lightsword, alright, yeah probably failure to enable heads/outputs will take a different exit path.
<Lightsword>
well technically a network KVM but same issue with real monitor there
<Lightsword>
also seems to be limited to the HDMI(DVI-D-1) interface, while VGA works
<mvlad>
Fyi, the transform changed to different values,
<mvlad>
The macro is of the format 0x$MAJOR$MINOR and does not include PATCH version. As mentioned in the Versioning scheme section, the latter does not reflect any user visible API changes, thus should be not considered part of the API version.
<mvlad>
libweston aims to guard all newly introduced API, in order to prevent subtle breaks that a simple recompile (against a newer version) might cause.
<mvlad>
All new symbols should be guarded by the macro like the example given below:
<mvlad>
Lightsword, don't see anything wrong with that log. You said that connectors worked...
<Lightsword>
mvlad, well only VGA seems to work, not the HDMI(DVI-D-1)
<Lightsword>
log is with HDMI
<mvlad>
Lightsword, maybe there's something going w/ that connector. You could try enabling DRM debug, like writing 0x1f to /sys/modules/drm/parameters/debug, while starting weston, then turning it off. Can also attempt to run plain modetest with a test mirror pattern and specify that connector and see if that brings it up -- while maybe trying various mode lines.
<Lightsword>
mvlad, huh, so adding CONFIG_FB_EFI=y to my kernel config gets it working looks like
bluepenquin_ has joined #wayland
bluepenquin_ has quit []
<mvlad>
Lightsword, did you had any output whatsoever, like console/tty at all before that? Don't know why that made it work though.
<Lightsword>
mvlad, without it output drops after bootloader hands off to kernel
<mvlad>
Lightsword, ah alright, then I guess that explains it.
<mvlad>
sort of :)
<Lightsword>
mvlad, assuming efifb is initializing something for the gma500 driver maybe?
<mvlad>
sorry, no idea.
* Lightsword
wonders why default on efifb was change in kernel defconfig
devilhorns has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
radu242 has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
ahartmetz has joined #wayland
fmuellner has joined #wayland
eroux has joined #wayland
nerdopolis has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
yoslin has quit [Quit: WeeChat 3.3]
yoslin has joined #wayland
<pq>
mvlad, I think those docs about REQUIRE_LIBWESTON_API_VERSION are all wishful thinking. I don't ever recall anything actually do that in libweston.
<pq>
that's actually what would be needed to fix that SDL issue with libwayland about using too new wayland-scanner, except it would need to be extended to scanner functionality as well
fmuellner has joined #wayland
<mvlad>
pq, yep, haven't seen those anywhere.... been doing some reading about forward compat, and had those in my clipboard.
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
duxsco has joined #wayland
bcheng has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
duxco has joined #wayland
duxsco has quit [Ping timeout: 480 seconds]
duxco has quit [Ping timeout: 480 seconds]
jgrulich has quit [Remote host closed the connection]
* macc24
remembers when everything was on one irc network
<macc24>
emersion: oh yea i flat-out just don't use sasl and manually log in ;D
<emersion>
that's fine
<emersion>
but no SASL support means IRC clients can't behave properly
<emersion>
(when it comes to authentication)
<macc24>
yeah
<zamundaaa[m]>
emersion: about the fractional scaling MR... It causes either sub-pixel offsets + buffers being stretched, or whole-pixel offsets + all kinds of size issues that I explained in the MR comment
<emersion>
that's what you say in the MR, yes
<emersion>
so, what's your proposal?
manuel has joined #wayland
<zamundaaa[m]>
The compositor needs to communicate everything in an already-scaled coordinate system, to at least have a commutable coordinate system as an option
<zamundaaa[m]>
In order to not have the same problems as the simple surface.scale approach, the compositor will need to have a higher resolution than the logical grid internally though.
<zamundaaa[m]>
Effectively, it needs to use floating point logical coordinates, or pixel coordinates directly
<vyivel>
how well will it play with a surface placed on two outputs with different scales at the same time?
<macc24>
how would it impact performance?
<zamundaaa[m]>
vyivel: on the less important output it will be blurry, but we have that, whatever you do. Other than that, it would be fine
<zamundaaa[m]>
macc24: it gives apps the exact resolution to render to (if the compositor wants that), it would be just like without any scaling
<emersion>
"communicate everything in an already-scaled coordinate system"
<emersion>
complexity goes through the roof with this approach
<zamundaaa[m]>
The issue is not performance or multi-monitor, the issue is that it's rather hard to implement
<macc24>
zamundaaa[m]: wouldn't usage of floating point coordinates just wreck the performance on slower systems?
<zamundaaa[m]>
emersion: true. I don't really see a different way of going about it without compromising functionality :(
<vyivel>
implementation complexity aside, does this approach have any other downsides?
<macc24>
i wonder if it would be possible to implement curvilinear coordinates in weston
<vyivel>
w-why
<macc24>
because it would be funny
<vyivel>
the greatest motivation
<zamundaaa[m]>
vyivel: I don't know of any, no. The implementation complexity is potentially on the scale of "rewrite a third of the compositor" though, so if there is a better approach that would be great
<zamundaaa[m]>
macc24: unless you lack an FPU, using floats in the compositor will not cause noticable performance problems
<danieldg>
since the compositor controls the allowed set of scales, it could choose to limit itself to ones that are simple to do in integer/fixed-point math on no-FPU systems
hergertme has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
hergertme has joined #wayland
<zamundaaa[m]>
On a different topic, how does the lifetime of immutable drm blobs work?
<zamundaaa[m]>
In KWin I've come across the situation where the kernel seems to swap out blob IDs in between me calling drmModeObjectGetProperties and drmModeGetPropertyBlob, which causes some pretty annoying problems
caef^ has joined #wayland
<zamundaaa[m]>
Shortening the amount of code in between the two calls makes it work again, but that's obviously not something I want to rely on. In libdrm and the kernel I don't really see anything obvious about this
MajorBiscuit has joined #wayland
<daniels>
zamundaaa[m]: which blob changes?
<daniels>
the blob is accessible for as long as it’s the current property value + for user-created blobs, also until the user destroys it (implicit if the device gets closed)
<daniels>
whichever of those two is longer
<daniels>
you shouldn’t see the prop change unless you destroy what you created (that’s your problem), or for something like EDID it should only change on hotplug
<zamundaaa[m]>
EDID and TILE changed IDs
<emersion>
likely a hotplug event happened then
<daniels>
yep
<zamundaaa[m]>
AFAICT from the logs the user gave me, it did not
<daniels>
they’re small tho so just cache them when you first probe the connector
<daniels>
and if you fail to get them, you should see a hotplug event really
<daniels>
I can’t see how else they’d change from under you
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
I do get them when probing the connector - it was just that the TILE was fetched after parsing some other stuff, including the EDID, and now I'm sort of questioning the reliability of it all...
<daniels>
it shouldn’t change in that span, no
<zamundaaa[m]>
Very annoyingly, in that case the TILE blob had the value of the EDID blob. Which is a nice exercise for properly checking input validity, but not great otherwise
<emersion>
fun race conditions
<emersion>
i've never seen this happen, that said, so i'm a bit surprised
<zamundaaa[m]>
This is not confirmed yet, but we have a bug report where the edid blob is always invalid with NVidia GPUs... I suspect it's the same problem.
<zamundaaa[m]>
I just hoped that someone would tell me the API was designed with properties being changed in mind... I guess not :/
<daniels>
if it’s NV driver, then in all honesty I’d jump straight to assuming a bug there
<emersion>
^
devilhorns has quit []
<zamundaaa[m]>
True, but it working on GNOME does make me wonder. I guess I'll find out once one of the users tests the patch I have for it
<jadahl>
zamundaaa[m]: if its a timing issue, maybe mutter is just lucky parsing the tile property
jmdaemon has joined #wayland
<zamundaaa[m]>
Maybe
caef^ has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
<kennylevinsen>
zamundaaa[m]: I'm pretty sure we agree on all the math - the question is what we consider acceptable compromise and within scope (or possible to handle separately as an incremental improvement)
<vsyrjala>
it doesn't look like we generally do anything to avoid changing the blob when the data didn't change
<emersion>
that shouldn't be too much of an issue
<vsyrjala>
it can explain the blob id clash
<emersion>
the more important issue is not re-using a blob ID for two consecutive hotplugs
<vsyrjala>
eg. first we replace the edid blob, which frees up the old id, then we replace the tile blob which now takes up the freed id
<emersion>
yup
grawity has left #wayland [#wayland]
<emersion>
but checking whether the data changed wouldn't help in all cases
<emersion>
e.g. a flaky dock could have a rapid unplug+plug event
<emersion>
re-using the same blob ID would cause the same issue
<vsyrjala>
right. hmm. is there any way to do 100% race free getblob?
<emersion>
the kernel would need to send a ping to all KMS clients
<emersion>
the wait for all of them to pong
<emersion>
then drop the blob ID
<emersion>
obviously this is a bit involved
<vsyrjala>
or could maybe add a serial number to each blob id property?
<zamundaaa[m]>
There is an easier way
<emersion>
the quick'n'dirty way is to keep the blob ID for a while (e.g. 1min)
<zamundaaa[m]>
Make a replacement function for drmModeObjectGetProperties that takes a reference on the blobs
<emersion>
zamundaaa[m]: there's still a race between the hotplug and the drmModeObjectGetProperties call
<emersion>
hm
<emersion>
actually it may not. but in any case the state fetched by user-space might be corrupted
<emersion>
half-old, half-new
<emersion>
because there are so many "get this data" IOCTLs
<vsyrjala>
serial numbers wouldn't need any new uabi. if it's there you check it, if not you live with the race. just not sure i really like adding a second prop for each blob
<vsyrjala>
i guess you'd only really need them for the immutable props that can change on their own
duxsco has joined #wayland
mvlad has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
jmdaemon has quit [Remote host closed the connection]
radu242 has quit [Quit: Ping timeout (120 seconds)]
radu242 has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
duxsco has quit [Quit: duxsco]
radu242 has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
cvmn has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
hardening has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
_whitelogger has joined #wayland
nerdopolis has joined #wayland
ishitatsuyuki has joined #wayland
mtj has joined #wayland
Net147 has joined #wayland
amosbird has joined #wayland
AJ_Z0 has quit [Quit: I have to return some videotapes]
AJ_Z0 has joined #wayland
jbit has joined #wayland
Dami_Lu has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.4]
caef^ has joined #wayland
tzimmermann_ has joined #wayland
tzimmermann has quit [Ping timeout: 480 seconds]
manuel_ has joined #wayland
manuel has quit [Remote host closed the connection]