I hate how the driver works. So omaplcd passes mbxaccess a .so filename which passes it to its clients which dlopen it which use it to access the /dev/omaplcd device node which gets back to omaplcd again which eventually sets omap dss registers on its own or calls mbxaccess.

This is clearly designed so that the author of display class device drivers can choose whether to implement most of the logic in user space or kernel space -- If we could follow this we could create a libomaplcd.so replacement which calls into blizzard/xv/omaplcd/whatever user space library you can think of.

But of course, we can't.