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

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

[Ilyes Gouta]

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

Hi,

Is it possible, as of today, to emulate a classic Linux framebuffer when
using qemu linux-user mode?

At a first glance, I saw in the code that
FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
declared by couldn't locate where they're handled. Are these hooked to the
SDL back-end?

Thanks,

-Ilyes

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

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

[Blue Swirl]

On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta <ilyes.gouta@gmail.com> wrote:
> Hi,
> Is it possible, as of today, to emulate a classic Linux framebuffer when
> using qemu linux-user mode?
> At a first glance, I saw in the code that
> FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
> declared by couldn't locate where they're handled. Are these hooked to the
> SDL back-end?

SDL is only used for system emulation. It should be possible to add
conversions (for example, from PPC 32 bit BE to x86_64 64 bit LE) for
FB ioctls in order to pass them to the host FB device. But what would
be the use case for this?

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

[Ilyes Gouta]

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

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?
>
> Thanks,
>
> -Ilyes
>
>
> On Thu, Sep 9, 2010 at 9:28 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>
>> On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta <ilyes.gouta@gmail.com>
>> wrote:
>> > Hi,
>> > Is it possible, as of today, to emulate a classic Linux framebuffer when
>> > using qemu linux-user mode?
>> > At a first glance, I saw in the code that
>> > FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
>> > declared by couldn't locate where they're handled. Are these hooked to
>> the
>> > SDL back-end?
>>
>> SDL is only used for system emulation. It should be possible to add
>> conversions (for example, from PPC 32 bit BE to x86_64 64 bit LE) for
>> FB ioctls in order to pass them to the host FB device. But what would
>> be the use case for this?
>>
>
>

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

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

[Alexander Graf]

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.


Alex

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

[Ilyes Gouta]

[-- 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 --]

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

[Ilyes Gouta]

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

Hi,

> No, but it could be possible to convert the DirectFB ioctl structures
> between guest and host. Other ioctls are translated this way. I guess
> nobody has cared about framebuffer support yet.

DirectFB (on the sh4 side) is just a client which is interacting with the
framebuffer. It doesn't have its "own" set of ioctls.

Is handling FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO
enough to abstract a basic Linux framebuffer and emulate it (by not
forwarding these to a native framebuffer)?

-Ilyes

On Thu, Sep 9, 2010 at 9:57 PM, Blue Swirl <blauwirbel@gmail.com> wrote:

> On Thu, Sep 9, 2010 at 8: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?
>
> No, but it could be possible to convert the DirectFB ioctl structures
> between guest and host. Other ioctls are translated this way. I guess
> nobody has cared about framebuffer support yet.
>
> See linux-user/ioctls.h.
>
> > Thanks,
> > -Ilyes
> >
> > On Thu, Sep 9, 2010 at 9:28 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> >>
> >> On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta <ilyes.gouta@gmail.com>
> wrote:
> >> > Hi,
> >> > Is it possible, as of today, to emulate a classic Linux framebuffer
> when
> >> > using qemu linux-user mode?
> >> > At a first glance, I saw in the code that
> >> > FBIOGET_FSCREENINFO, FBIOGET_VSCREENINFO and FBIOPUT_VSCREENINFO being
> >> > declared by couldn't locate where they're handled. Are these hooked to
> >> > the
> >> > SDL back-end?
> >>
> >> SDL is only used for system emulation. It should be possible to add
> >> conversions (for example, from PPC 32 bit BE to x86_64 64 bit LE) for
> >> FB ioctls in order to pass them to the host FB device. But what would
> >> be the use case for this?
> >
> >
>

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