On Thu, Sep 9, 2010 at 11:57 PM, Alexander Graf <ag...@suse.de> wrote:
> > On 09.09.2010, at 23:06, Ilyes Gouta wrote: > > > > > > > On Thu, Sep 9, 2010 at 9:39 PM, Ilyes Gouta <ilyes.go...@gmail.com> > wrote: > > Hi, > > > > Well, actually I'd like to run sh4 binaries in linux-user mode, where > these are actually DirectFB applications which rely on the standard Linux > framebuffer to display things. > > > > In my use case, I'd like to route these ioctl in qemu to be handled by > the SDL back-end (or even a DirectFB instance running on the host) instead > of being dispatched to the native framebuffer driver, running on the host. > > > > Is this feature available in the current qemu code base? > > Please don't top post. > > It is not available in qemu and doesn't belong there. Qemu's linux-user > target really only passes things through. It shouldn't intercept them and > try to be clever. That's the task of the surrounding stack. > > For example in your case, I'd write an LD_PRELOAD that would trap open on > /dev/fb* and emulates mmap and ioctls to that device. This way you get a > generic way of displaying fb contents in windows that might be useful for > other use cases too. > > Another thing you could look into is cuse. Maybe you could expose /dev/fb0 > as a cuse device and trap things through that. Indeed, it sounds a lot more generic. I already started hacking into qemu to implement (prototype) rerouting the framebuffer ioctls, and it's surprisingly easy :) If cuse's learning curve isn't stiff, I'll consider moving my changes into a separate shared library. Thanks Alex, -Ilyes > Alex > >
