On 12/20/2017 10:43 AM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: >> On 12/19/2017 06:26 PM, Daniel Vetter wrote: >>> So essentially you're telling me that on a current general purpose >>> distro the gfx driver loading is a dumpster fire, and we're fixing >>> this by ignoring it an adding a hole new layer on top. That doesn't >>> sound like any kind of good idea to me. >> >> Yes. It is a vast improvement over the status quo, and people are asking >> for it. And the bootsplash layer can be moved elsewhere, just change the >> hooks and keep the loading/rendering. >> >> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It >> just mustn't be done 100% carelessly. > > You've talked about using sleep and stuff to paper over races. That > doesn't sound good at all. Sorry, I was unclear. It's Plymouth's ShowDelay that, unintentionally, papers over this bug. The driver loading bug will happen with any user based splash - it's not limited to Plymouth. On the other hand, if you don't start a graphical application before having loaded the final graphics driver, everything is good and there is no race. So, module loading works as intended ;) >>> So if just using drm for everything isn't possible (since drm drivers >>> can at least in theory be hotunplugged), can we at least fix the >>> existing fbdev kernel bugs? Not being able to unplug a drm driver when >>> it's still open sounds like a rather serious issues that probably >>> should be fixed anyway ... so we're better able to hotunplug an fbdev >>> driver when it's in use. >> >> I don't see it as a bug. The fbdev driver gets unloaded as much as >> possible, but as long as a userspace application keeps the address_space >> mmap()ed, there's nothing we can do, short of forcibly removing it and >> segfaulting the process the next time it tries to render something. Am I >> missing something? > > I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering > in a sighandler and abort if you hit that. In drm we try to be a bit > better and keep things around until userspace has gone. Hmm. Are you sure it's okay to SIG these processes just because someone else has decided to unload a driver? That is counter to everything else that I've seen so far. Also, is it even feasible, implementation wise? >>> Or we get simpledrm merged (for efifb and vesafb support) and someone >>> types the xendrm driver (there is floating around, it's just old) and >>> we could forget about any real fbdev drivers except the drm based >>> ones. >> >> And drmcon, unless we come up with a better idea than hooking into the *con driver. > > If we have everything as drm drivers, you can just use plymouth (with no > fbdev backend ofc) and everyone is happy. Including the efifb folks (it's > simply going to be called efidrmfb or something like that). So no idea why > you need a *con. Hmm, that still makes us wait until userspace has appeared... And the reason I built it into *con is because the logic for appearing/disappearing is basically the same, and in this chain it makes sense for the bootsplash show/hide logic to be chained behind *con. >> Sure, that'd help a lot. But what do we do until then? > > Make it happen? Twiddling thumbs is an option too ofc, but it tends to not > result in results :-) I'm afraid I don't have the time to write an in-kernel terminal emulator, thus the wish to build upon the existing one... _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
