Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user

[Ilyes Gouta <ilyes.gouta@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On Thu, Sep 9, 2010 at 11:57 PM, Alexander Graf <agraf@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.gouta@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
>
>

[-- Attachment #2: Type: text/html, Size: 2432 bytes --]