Od: Wolf Ramovsky " > There needs to be some kind of hand-off between kfb and vesafb, both > drivers need to coexist side-by-side in a limited way.
To be honest, I don't have any idea how to do it in an elegant way. May be we should disable autoloading and load drivers explicitly by compositor? Is there a mechanism to load drivers on demand?" By design we try to build a tree of all devices present in the system and attach drivers, if possible. I do believe this is a typical scenario that any device framework, including ours, can handle. Simply the parent driver / match file need to be adjusted so that there is one device which can be handled either by vesafb or kfb. Vesafb will be given higher priority. So it will first try vesafb and, if that fails to attach, fall back to kfb. I don't think we've tested this scenario, but it should work. And if it doesn't, it would need to be fixed :-) "> * The solution with the separate thread in vesafb is not very elegant. > You should first initialize the hardware (port_init()) and only after > the initialization succeeds register the DDF function. Well, then what to do with compositor which starts before driver? """ It's a bug. Compositor first tries to connect to the visualiser using devman _device_connect() before falling back to loc_service_connect()?! Now using devman_device_connect() is not wrong, it's the 'old' way of doing things. It should really just use loc_service_connect() - I have no idea why it does it both ways. Now there's a bug in the code that handles devman_device_connect() on the server side (devman_forward() function). It will refuse to forward the call unless the driver has returned from its dev_add handler. This is a historical remnant aswell. Devman should forward calls to the driver through any function as soon as it's bound (i.e. becomes visible to the outside). I'll fix this hopefully tomorrow :-D Cheers, Jiri
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
