> Well, hotplug is alreay a giant pain because of the single lock to rule > them all design of the current kms code: Long delays already stall > everything else (well, cursor updates and pageflips) and we have tons of Yes I hit this with the gma500, it's one reason I did the GTT based scrolling. > bugreports that complain about it. In a sense your example undermines my > point that we have lower hanger fruit to fix all over the place already ... Yes.. I'm trying to stop the rotting fruit getting any further down the tree! The KMS locking isn't just a KMS problem, KMS inherits some of it from the framebuffer which inherits some of it from printk which gets some of it from panic an in IRQ error handling. It's all very messy as a result. I keep poking at the vt and tty layer end of this to try and sort it out from the bottom but it's like a bad cess pit, every time you poke it the smell drives you back to other things. > But as I've said I like the WARN_ON you want to add, but otoh hand think > it shouldn't be used to stall the small&hackish fix of adding the relevant > in_atomic checks. Then I think we basically agree. Alan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
