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
nsneck has quit [Quit: bye]
nsneck has joined #wayland
cabal704 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
maxzor has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
tzimmermann_ has joined #wayland
tzimmermann has quit [Ping timeout: 480 seconds]
fmuellner_ has quit [Ping timeout: 480 seconds]
tanty has quit [Ping timeout: 480 seconds]
tanty has joined #wayland
evon37 has quit [Ping timeout: 480 seconds]
damjan has quit [Remote host closed the connection]
damjan has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
d3x0r has joined #wayland
d3x0r is now known as Decker
evon37 has joined #wayland
evon377 has joined #wayland
evon37 has quit [Ping timeout: 480 seconds]
<Decker>
I had my wayland driver working pretty well; on kde plasma and native wayland; this is actually on rdp and maybe that's a difference... 1) the screen size I get is 0,0,0,0 2) I get a request that something wants to draw (request the pixel buffer), so I create a buffer, and attach it to the surface; eventually the code finishes drawing and calls something to update to the screen; which does damage and a commit(unless the frame callback
<Decker>
hasn't triggered, then it just damages the surface and waits).... when a commit will happen...
<Decker>
I create a new surface and buffer, expecting to not be able to write to the one I'm committing until it's released... so I do the commit and attach a new surface
shankaru has joined #wayland
<Decker>
and carry on drawing; if another commit needs to happen, though, the first buffer is never actually released, until I commit attaching the second buffer
<Decker>
(so now I end up having to triple buffer, so I can have one more that I can return to the application to draw, because I don't know how long I would have to wait for a release after the second attach is commited
<Decker>
the frame callback isn't really like a 'surface is free'? or is it? It implies that I should be able to draw to the existing surface (even though it's not released, and random reads could happen while I'm in the middle of updating?)
maxzor has joined #wayland
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
masoudd has quit [Ping timeout: 480 seconds]
Azem has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
Emet-Selch has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
shankaru has quit [Read error: Connection reset by peer]
ahartmetz has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
rpigott has quit [Remote host closed the connection]
rpigott has joined #wayland
tzimmermann_ has quit []
tzimmermann has joined #wayland
dcz_ has joined #wayland
eroux has joined #wayland
spstarr has joined #wayland
jmdaemon has joined #wayland
jgrulich has joined #wayland
sillyslux has quit [Read error: Connection reset by peer]
maxzor_ has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
mvlad has joined #wayland
sillyslux has joined #wayland
<kennylevinsen>
Decker: frame callback only means "now is probably a good time to prepare new content".
<kennylevinsen>
You are *never* allowed to write to a buffer before it is released
jmdaemon has quit [Remote host closed the connection]
maxzor_ has joined #wayland
jmdaemon has joined #wayland
maxzor_ is now known as maxzor
l4s8g_ has joined #wayland
l4s8g has quit [Ping timeout: 480 seconds]
deepin has joined #wayland
deepin is now known as Guest303
<pq>
Decker, maybe start from the top: what wayland driver? And why would you be creating new surfaces like that? How you use frame callbacks also sounds odd, but maybe I just didn't understand.
<Decker>
pq sure uhm
<pq>
Decker, you never draw to surfaces anyway. You draw into buffers.
jmdaemon has quit [Ping timeout: 480 seconds]
<pq>
and yes, if you want to be able to draw at any time all the time, you are likely going to need 3 or 4 buffers in total.
<pq>
but no new surfaces
<Decker>
oh? that's a detail I think I missed
<pq>
It's ok to attach+damage+commit on a wl_surface at any time when the surface is mapped.
<pq>
If you attach+damage+commit before the frame callback from the previous attach+damage+frame+commit returns, it is possible the compositor will drop your previous update to the surface, meaning you wasted work by drawing it in the first place.
<Decker>
okay if I attach+damage+commit+attach +damage(...)
<Decker>
and in the meantime I get back a frame callback ( but no release)
<pq>
frame callbacks and buffer releases are completely unrelated to each other
<Decker>
after (or during) the surface frame callback I can then commit
<Decker>
but at this point I have to have at least 2 buffers (not surfaces my bad) it's _surface_attach() so... surface... (no; gotit, but that's why I said surface and not buffer)
<Decker>
but really after the commit I need a new buffer, so that's 3
<Decker>
because yes, it is 'able to draw at any time'
<pq>
right, you need 3 because: one still reserver in the compositor, one you just sent to the compositor, and one to draw into.
<Decker>
and then I get locked because now I'mnot getting any buffer releases
<pq>
this can also grow up to needing a fourth buffer to draw into, as the compositor may temporarily hold on to three.
<Decker>
I can add a wl_surface_commit() immedaitly after every attach() and that 'works' flickers a lot... but I get buffer releases
<pq>
but that's usually transient, and if you stop at three buffers and then wait for releases, you get blocked by one refresh cycle maybe
<Decker>
which makes it not hold onto buffers
<Decker>
at this point it deadlocks with 3 locks and 0 releases
<pq>
wait, what?
<pq>
attach does nothing if you do not *also* commit after it
<Decker>
I'm also using MSTSC connected to wayland rdp that's the compositor
<Decker>
it schedules a buffer to be applied... so I can apply damages to it
<Decker>
and THEN commit sure... but not before doing any damage
<pq>
you are supposed to construct "transactions" from attach, damage and frame requests, then latch it with a commit.
<pq>
committing "in between" is not good.
<Decker>
right. tht's what I was doing and was working fine.
<Decker>
right.
<Decker>
I get that.
<pq>
what's the problem?
<Decker>
that it doesnt' work unless I do what I'm not supposed to do?
<pq>
what doesn't work?
<Decker>
again, commiting after the attach with RDP works, and I get buffer unlocks. WIthout that I don't get buffer unlocks.
<Decker>
I am about to extend this to N frames outstanding... and I expect it will still deadlock
<pq>
I'm afraid I need more context than that.
<pq>
why do you think it will still deadlock?
<pq>
Are talking about Weston with RDP-backend, or something else?
<pq>
*Are we
<Decker>
yes; I think that's a notable difference; the other was on bare hardware; I could go test there... but I'm working here now.... (the RDP)
<pq>
The only difference with RDP-backend in Weston is that I think it has no outputs at all when no RDP client is connected. That means it will not reply to frame callbacks at all, until a client connects.
<pq>
This is normal, and can happen also on DRM-backend then e.g. the compositor goes to sleep.
<pq>
*when
<pq>
However, this does not affect buffer releases.
<pq>
When a Wayland client submits a new buffer and that makes the old reserved buffer free, a buffer release event will be sent.
<Decker>
I'd think so
<Decker>
But... if I don't give it a new buffer, it doesn't unlock the old one... and if I give it a enw buffer which is also damaged it doesn't release it
<Decker>
if I don't give it another buffer there'd be no reason to release...
<Decker>
which is why I could see 3 frame buffers making it work just fine
<pq>
How does you event loop integration look like?
<pq>
I'm wondering if you somehow end up e.g. not flushing outgoing requests to the socket, or not waiting for events correctly, or maybe doing a nested dispatch.
<MrCooper>
Decker: "commiting after the attach with RDP works, [...]. WIthout that I don't get buffer unlocks" ← attach without commit does nothing
<pq>
yeah, but Weston's RDP
Guest303 has quit [Ping timeout: 480 seconds]
<pq>
yeah, but Weston's RDP-backend also only uses Pixman-renderer, which will always release buffers without a replacement anyway, on the next refresh. Ah, but RDP-backend does not refresh without an RDP client...
<pq>
Decker, I have a hard time understanding your code, but I did notice a mention to threads. Are you using Wayland from multiple threads?
<pq>
I found a call to wl_display_flush() in the middle of a request sending sequence, which makes the think your event loop doesn't really work right and the flush is a band-aid to something.
<Decker>
I've been removing those
<kennylevinsen>
You're dispatching your main queue in that thread, so that tries to handle everything. Any callback might run from that thread, e.g. frame callback or buffer release.
<Decker>
yup
<Decker>
all should actually
<Decker>
so they have a unique log ID
<pq>
but are you still sending requests from the other thread too?
<pq>
where does the other thread sleep?
<Decker>
https://i.ibb.co/tHkLRKd/image.png the 12 digt hex number is process and thread id... this is as far aws it gets with 3 buffers, and 0 releases
<pq>
you have at least 4 threads?
<Decker>
actually draws are posted to come back in on that thrad
<Decker>
3 probably
<pq>
one thing is that any thread that sends requests must wl_display_flush() before any sleeping if it doesn't call any other wayland function that would flush.
<Decker>
ya turns out to be 4....
<Decker>
okay there's nothing I know of that really flushes that I use (especially in this test which is just a clock..)
<Decker>
so put flushes back in? should I do a ful round trip wait?
<pq>
if you don't flush, the compositor does not get your replacement buffer commit, and will not send a release either,
<pq>
No, don't put flushes "back in", but put it just before the thread goes to sleep?
<pq>
-?
<pq>
also you should not use wl_display_roundtrip*() at all after your event loop has started.
<pq>
wl_display_roundtrip*() will dispatch any and all events coming on that queue until it finishes the roundtrip.
fmuellner_ has joined #wayland
<pq>
so it's another dispatch point
<pq>
also, if you call roundtrip from inside an event handler, you are doing nested dispatch, which is a really bad idea.
<kennylevinsen>
For reference, the flow should be: render to next unused buffer -> attach -> damage -> register frame callback -> commit -> flush. The flush should be done at the end of your event loop or something to flush everything queued, not at each place you write something. If this doesn't work (e.g. never getting any buffers released), something is broken - and if threads are involved, it's likely
<kennylevinsen>
that. :P
<kennylevinsen>
You should never need roundtrips and should only need one dispatch/flush location after setup.
<Decker>
wl_display_dispatch_queue is supposed to have a sleep?
<Decker>
ya the round trips haven't been there since I started fixing this for RDP
rasterman has joined #wayland
<Decker>
still not getting any buffer releases... and I'm stuck at 2 for some reason :/
<pq>
Decker, wl_display_dispatch_queue can sleep, but it also flushes.
<pq>
Decker, one thing your could try is set WAYLAND_DEBUG=server for Weston, and WAYLAND_DEBUG=client for your app, and then compare the protocol logs up to getting stuck.
<pq>
These will make libwayland print the protocol messages as they are dispatched or send-queued.
<pq>
If you see the client send a request, but you do not see the compositor receiving it, it means you didn't flush.
immibis is now known as Guest305
immibis has joined #wayland
<pq>
protocol logs might be easier for us to read, too, than your own debug messages or code - then we can at least say if the messaging sequence has something odd
rv1sr has quit []
Guest305 has quit [Ping timeout: 480 seconds]
<Decker>
blah - just updating damaged areas doesn't work for 5 buffers... worked good for 2
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Decker>
https://gist.github.com/d3x0r/9d9f601ad6dd1112056dd1c9ad84e076#file-test-log-L176 enabled wayland debug on client... this is an attach where I don't have more buffers available And really from line 173 that's the last commit, I don't do another commit until I get a frame callback... but I do have room to make a new buffer, so it does, and schedules an attach and does a lot of damaging...
<Decker>
eventually I hit a key I guess to switch back? and that woke it up?
<Decker>
There's a second run that starts at line 352
flacks_ has quit [Quit: Quitter]
flacks has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
<pq>
Decker, at least you do seem to have "stray" damage and commit requests in that log, but those shouldn't cause deadlocks.
<Decker>
ya but I think it's all scheduled to a single thread to actually draw... the init is done on tha main thread and missing fonts don'tmatter
<pq>
sorry, how is that relevant?
<pq>
Decker, I think I see a couple frame+damage+commit cycles without an attach.
<Decker>
well no I guess not there is definitly some cross thread ops
<Decker>
can't damage without an attach...
<Decker>
and can't commit without a commit - but once there's one attach there's something attached
<Decker>
so I don't see how I could do anything without an attach, if I didn't have a buffer when doing a commit that could be attached - that's when it locked
<pq>
sorry?
<Decker>
it does stall - but it also does run... I think 5 is a safe min ... I have it set to 10 outstanding; and no smarts that if it didn't NEED 10 it'll still make 10
<pq>
damage+commit without an attach does not make sense, because you are not allowed to draw into a reserved buffer, and quite likely the previous buffer is still reserved.
<Decker>
I'm saying that can't happen so I don't think you're seeing what you think you're seeing?
<Decker>
in both logs thre's an attach before any damage
<pq>
It would be nice if you could have a single function that does the frame+attach+damage+commit sequence in one ago, and nothing else would attach non-NULL buffers or send damage.
<Decker>
ya that null is the first buffer isn't used - it starts at the first next which is '1' so that null sits there until all 10 are used
<pq>
you're right, attaches are there
<pq>
some redundant damage though, but that doesn't hurt
<pq>
Decker, what throttles your drawing?
<pq>
Decker, I don't think you are re-using the buffers that were released, are you?
<pq>
I see creating new buffers even after getting a release
<pq>
the protocol sequence looks strange though, creating a new buffer before committing the previous one
<Decker>
:) I don't know what makes it go tick, I think it's recusion though the draw function
cabal704 has joined #wayland
<Decker>
well ya I want to make sure I have a space to draw when I can't draw
<pq>
uh, you don't know the structure of your program?
<pq>
recursion does not sound good
eroux has joined #wayland
<pq>
if you allocate a new buffer just-in-case when committing the current one, that's just +1 to max number of buffers you might need in your pool.
<pq>
not allocate, but ensure that there is at least one free and allocate if none free
<Decker>
ahh found it - it reschedules the draw from 100 milliseconds from 'now' (which is after the draw happens)
<pq>
Decker, I see that you are getting frame callbacks, and you are getting buffer releases, and the protocol sequence is not too broken, so the only thing I can conluce is that the problem is in your program structure.
<pq>
*conclude
<Decker>
psh there's not a lot of structure - it's really self contained in that - I think I could mostly just add a 'main' and bypass making/updating iamges
<pq>
and with threads, likely
<Decker>
bah
<Decker>
and RDP
<pq>
bah to you too, if that's my thanks for spending a couple hours trying to help you.
<Decker>
because the same program worked fine other places
<pq>
that's the thing with threads: even the smallest changes in environment can make the program behave completely differently.
<pq>
There is no reason visible in the protocol log why you would run out of free buffers.
<Decker>
not when it's a single thing that's being done. 1 execution path coordinated between threads.
<pq>
You do get the buffer releases.
<Decker>
ya have 5 buffers
<Decker>
sorry ya after 5 buffers
<pq>
er, did you show me a protocol log of a case that does *not* exhibit the problem?
<Decker>
that's just want I want to do - pentuple buffer my applications :)
<Decker>
no those are all problems. Want I should add the hack that makes it work?
<Decker>
it's a wl_surface_commit() directly after the surface_attach()
<pq>
Given it is Weston RDP-backend, you literally should not need more than 2 buffers. With other backends and it you used GPU rendering, you might need up to 4. But not here. So going to back to 2 buffers is fine, and continue debugging.
<Decker>
2 is a lock.
<pq>
I know.
<Decker>
with no buffer releases wanna see that? ok.
<mjt>
Hi! What's the minimal X environment to run a thin client with single X application (considering xfreerdp)? Xwayland seems like a good fit, right?
<mjt>
(complete xorg server seems to be too large for the task)
<LaserEyess>
xwayland is a "complete" X server
<LaserEyess>
do you really want a "minimal" environment to be Xwayland on top of wayland?
<mjt>
well, I'd love to have no X11 in-between but so far it doesn't work :)
<LaserEyess>
I have no idea if xfreerdp would work in that case either
<mjt>
it does
<mjt>
there's wlfreerdp but it is buggy (or maybe it is weston who's buggy, I dunno)
<LaserEyess>
you could look into wayvnc, and using something like cage
<kennylevinsen>
if you want to run X apps however then the most minimal option is to run a bare X server with nothing else
<kennylevinsen>
the issue says it happens only in weston
<kennylevinsen>
You could try sway
<mjt>
this is what I'm running right now :)
<mjt>
I need some terminal, sway suggests foot, and in foot, colors are just awful in dialog(1) (dark blue text on blue background - unreadable). I dunno who's fault it is and how to configure it. IN weston-terminal it looks fine :))
<mjt>
btw, in weston-terminal dialog(1) does not display borders
<kennylevinsen>
Just change the colors
<mjt>
heh. Use the source, Luke :)
<LaserEyess>
you could just run weston-terminal in sway...
<kennylevinsen>
It's user configurable in those terminal emulators
<dnkl>
mjt: foot _does_ have a configuration file..
<mjt>
actually I tried. But I don't know which colors dialog(1) choose - there are many of them in the palette. Looked at its source, started reading terminfo stuff, digged too deep, stepped back and tried xfreerdp which - surprizingly - worked. So I come here asking if xwayland is good :)
eroux has joined #wayland
<mjt>
looking at foot source - there are different themes even. maybe trying to find (in source again, since there's nothing about it in the manpages) how to switch them.. 'hwell ;))
<dnkl>
mjt: all terminals work the same way - there are 8 base colors you can set, and 8 corresponding "bright" shades
<dnkl>
"themes" are just a convenient way of setting them all at once
zebrag has joined #wayland
<dnkl>
(for foot, just do "include=path-to-theme-file" in foot.ini)
eroux_ has quit [Ping timeout: 480 seconds]
<mjt>
heh. I wish I knew about include= :))
<mjt>
thank you!
<dnkl>
Np
<mjt>
btw, wlfreerdp+weston mouse issue comes from cursor hotspot. It looks like each time freerdp changes mouse cursor its actual display positions moves by its hotspot coordinates.
<mjt>
from freerdp side it all loooks right, but the position of the cursor is wrong
<mjt>
wl_surface_attach() doc say: "The x and y arguments specify the location of the new pending buffer's upper left corner, *relative to the current* buffer's upper left corner, in surface-local coordinates" - I wonder if it should first substract current coordinates.. But I know nothing about wayland protocol
<kennylevinsen>
No that is unusual and should be zero
<kennylevinsen>
Ah
<kennylevinsen>
The hotspot is moved if you pass non-zero attach values
sillyslux has joined #wayland
<kennylevinsen>
But try with zero first, it's weird
<mjt>
rebuilding..
<mjt>
kennylevinsen: reportedly some other apps fail in similar way under weston
<mjt>
exactly the same - mouse cursor position is off by cursor's hotspot
<mjt>
but it doesn't happen under sway
<mjt>
(and does happen under gnome)
<mjt>
*sigh* I damaged my test environment yesterday after all the experiments :))
cvmn has joined #wayland
<mjt>
it seems this wl_surface_attach() call changes nothing - the cursor is off by exactly the same amount
rv1sr has joined #wayland
<kennylevinsen>
But I thought you saw the issue under sway as well?
<kennylevinsen>
I imagine we ignore the attach position in sway
<kennylevinsen>
I recall removing the handling of that altogether
<kennylevinsen>
Weston probably respects it
<mjt>
no, it works fine under sway
<kennylevinsen>
I may just misremember, but if I'm right then things don't work because Weston does things *right* and the app is buggy
cabal704 has joined #wayland
<mjt>
I should not act as a broken phone. I know nothig about wayland protocol/api and about freerdp internals :)
<kennylevinsen>
no worries
<kennylevinsen>
But if it works under sway then you have a solution - sway is pretty light.
<mjt>
yeah
<mjt>
I'm messing with colors in foot right now :))
<kennylevinsen>
open an issue with Weston, then we can discuss who is right there
___nick___ has joined #wayland
<kennylevinsen>
Might be that Weston is right and everyone else is wrong
rue has quit []
<mjt>
sure thing. I never tried to say who is wrong :)
<mjt>
wlfreerdp fails under gnome too
<mjt>
fails to display mouse cursor at the right position that is
<daniels>
kennylevinsen: obviously
<mjt>
btw, when xwayland is installed, and xwayland=true (the default) in weston.ini, sholdn't weston set $DISPLAY?
<mjt>
this is what sway does, at least
<daniels>
it should, and thought it did?
<mjt>
using weston from debian bullseye right now. xwayland is installed, /usr/bin/Xwayland exists. I run just 'weston' from shell on tty2 (or 'sway' for that matter).
<mjt>
under sway I see $DISPLAY, under weston there's no $DISPLAY
<mjt>
aha. --xwayland
rgallaispou has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<daniels>
did you put xwayland=true in the [core] section? just tried it here and it sets $DISPLAY when I do
<daniels>
(--xwayland does the same thing)
<mjt>
killall sway
<mjt>
um. mis-window
<mjt>
(I haven't found how to terminate sway yet ;) )
<mjt>
heh. It is xwayland=true vs xwayland = true :))
<mjt>
the latter (which I did) doesn't work
<daniels>
ugh
l4s8g_ has quit []
l4s8g has joined #wayland
txtsd has joined #wayland
fmuellner_ has joined #wayland
___nick___ has quit []
hardening_ has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
cvmn has quit [Remote host closed the connection]
macc24 has joined #wayland
<macc24>
would it be theoretically feasible to make weston not require udev?
l4s8g has quit [Ping timeout: 480 seconds]
<LaserEyess>
I think udev is required for getting input device information
<LaserEyess>
but eudev should work, too
<macc24>
uh
<macc24>
so starting eudev and setting eudev devices takes like a second or two
<macc24>
that's literally 30% of boot time of my device that has to run weston
<LaserEyess>
well, a 5 second look at weston's source code tells me udev is deeply integrated for the drm backend
<macc24>
... at this point i should probably switch over to using bare drmkms with sdl2 but i'd lose out on having more than one graphical program running at once
<LaserEyess>
so I would say it strongly depends on your definition of "feasibility"
<mjt>
gosh.. it looks like I was asleep.. udev.. eudev.. mdev.. :))
<macc24>
LaserEyess: on one hand it's a lot of work, but on the other hand i would be able to flex with 2 second boot time from cpu reset vector
<LaserEyess>
I'm not an expert in drm or how linux device enumeration works with udev (or how it doesn't work without it?)
<LaserEyess>
but it really seems like it's a hard requirement that would take a lot of pain to remove
<dottedmag>
maybe easier to profile eudev and see where it spends its time
<macc24>
dottedmag: on settling devices and making weston & eudev race each other by not settling before starting weston is a Bad Idea
<macc24>
i tried.
<LaserEyess>
that sounds like a bug in one or both software
<macc24>
LaserEyess: why?
<LaserEyess>
am I misunderstanding? You're saying weston is starting before eudev has all of the devices weston needs up
<LaserEyess>
or, that it's a race
<daniels>
macc24: you don't need to settle all your devices before you start Weston ...
<daniels>
macc24: it can deal with input hotplug entirely well; all you need is to ensure that the DRM device is available
<daniels>
which you can do with e.g. a systemd trigger
<macc24>
i don't have systemd on the device
<daniels>
you get to open-code that then :)
<macc24>
theoretically i can just write a script that would be like
<macc24>
`while weston; do true; done`
<macc24>
and just let weston continously crash until it works
<daniels>
well, you might want to add a sleep in there, otherwise you'll burn so much CPU that it'll take even longer ...
<macc24>
also
<macc24>
input device is already running by the time weston does /anything
<LaserEyess>
doesn't eudev emulate the udev interface for notifying that a device is ready?
<daniels>
right, so if you used that and waited for drm to become ready to start weston you'd be fine
<macc24>
huh
<LaserEyess>
just write a program to poll that and then start weston when what it needs is up
<LaserEyess>
yeah
<daniels>
settling _everything_ is unnecessary, since that's a full enumeration of every bus on your device, inspecting partition tables on storage devices, etc etc
<mjt>
btw, maybe switching from eudev to systemd+udev will solve all these probs?
<LaserEyess>
usually when people use eudev it means they don't want to use systemd on purpose
<macc24>
mjt: switching to systemd would multiply boot time by many times
<mjt>
if eudev already takes 30% of boot time..
<macc24>
daniels: if drm everything is copiled into kernel itself and /dev is devtmpfs would settling drm devices would be required?
<macc24>
mjt: 30% being around one second
<LaserEyess>
systemd boot times are not going to be more than 2 seconds, so it might actually save time
<LaserEyess>
or be at worst the same
<LaserEyess>
but sure, you don't want to do that
<mjt>
I'm building a thin client-like thing now - that sounds quite close :)
<mjt>
but I used regular debian as a base, and its boot time is mostly about reading stuff from usb flash
<mjt>
it's 300+Mb squashfs
<kennylevinsen>
macc24: technically possible to remove dependency by replacing it with something equivalent, e.g. libudev-zero or libdemi.
<kennylevinsen>
But would be a lot of work
<daniels>
macc24: yeah the settling is still required for coldplug
cabal704 has quit [Ping timeout: 480 seconds]
<macc24>
alrighty, thanks everyone
<macc24>
daniels: if you wanna know what i'm working on hit me up on /query
MajorBiscuit has joined #wayland
cabal704 has joined #wayland
masoudd has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
jmdaemon has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
fmuellner_ has quit [Ping timeout: 480 seconds]
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]