On Fri, Jan 25, 2013 at 1:50 AM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 25 Jan 2013 00:42:37 +0000 (GMT) > Dave Airlie <airlied@xxxxxxxx> wrote: > >> These patches have been sailing around long enough, waiting for a maintainer >> to reappear, so I've decided enough is enough, lockdep is kinda useful to have. >> >> Thanks to Daniel for annoying me enough :-) > > Me too, but the patches broke Maarten's EFI driver setup: > https://lkml.org/lkml/2013/1/15/203. Oops, didn't know that there are open issues, otherwise I'd have worked on fixes instead of annoying you guys. To make due I've crawled through fbcon code a bit to hunt for ways we could solve this mess better than just flinging duct-tape. All the patches extend the console_lock'ed area quite a bit, and I don't really like big kernel looks with creeping coverage. More so if they come with funny semantics like console_lock attached. Looking at the fb notifier there are three use-cases for it: - Special blank/unblank handling, used by the backlight and lcd drivers in the fbdev subsystem. Could easily be extracted to another notifier chain, and seems to have no need for the console lock. Also, for kms drivers I don't care about this one bit. - suspend/resume handling for the same fbdev lcd drivers. Same applies (besides that it probably should get converted to proper device model suspend/resume stuff). - Runtime dependency injection between fbdev (and vga_switcheroor) for fbcon. This allows you to load fbcon.ko and fbdev drives in any order, and end up with an fbcon on each fbdev. Or not load fbcon.ko at all, and only use the underlying fbdev. On a quick look it also racy as hell. The last one is the tricky one. If we could just add a hard (compile-time) dependency between fbdevs and fbcon, we could rip out all the fb notifier madness which also involves the console_lock in some way and should be able to straighten out the locking. Users could still opt out of using the fbcon at runtime, but ofc this might break a really obscure setup somewhere. Quick survey of distros shows though that all use the sane option of built-in fbcon support. My proposal is to change the fbcon tristate to a bool and see what happens. If it works out for a few kernel releases, garbage-collect the fb_notifier for fbcon and use direct function calls instead (stubbed it out properly if fbcon is disabeld ofc). Or is that too much bending of the "thou shalt not break stuff" rule? Plan B would be to simply mash-up a console on top of kms drivers directly (since that's what I care about). Which has the downside that we'd still need to keep the drm fbdev emulation helper code around, since quite a few people use that to run older userspace (and even report some bugs, e.g. mplayer on the linux console played some tricks we needed to catch). And so end up with two pieces of code who's main job is to paint console output onto the screen. Ideas? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
