From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56420 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Otoip-0006Gp-5r for qemu-devel@nongnu.org; Thu, 09 Sep 2010 17:31:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtoMG-0007ki-1V for qemu-devel@nongnu.org; Thu, 09 Sep 2010 17:08:37 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:58638) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtoME-0007jK-J0 for qemu-devel@nongnu.org; Thu, 09 Sep 2010 17:08:35 -0400 Received: by qwi4 with SMTP id 4so12373qwi.4 for ; Thu, 09 Sep 2010 14:08:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Ilyes Gouta Date: Thu, 9 Sep 2010 22:07:38 +0100 Message-ID: Subject: Re: [Qemu-devel] Linux framebuffer emulation in qemu linux-user Content-Type: multipart/alternative; boundary=001485f89a3c4e1bd9048fda060e List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --001485f89a3c4e1bd9048fda060e Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > On Thu, Sep 9, 2010 at 8:39 PM, Ilyes Gouta 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 wrote: > >> > >> On Thu, Sep 9, 2010 at 8:19 PM, Ilyes Gouta > 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? > > > > > --001485f89a3c4e1bd9048fda060e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

> No, but it could be possible t= o convert the DirectFB ioctl structures
>=A0between guest and = host. Other ioctls are translated this way. I guess
>=A0nobody= has cared about framebuffer support yet.

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

Is handling=A0FBIOGET_FSCREENINFO,=A0FBIOGET_VSCREENINFO and=A0FBIOP= UT_VSCREENINFO enough to abstract a basic Linux framebuffer and emulate it = (by not forwarding these to a native framebuffer)?

<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">-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 binarie= s 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 handle= d 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 frame= buffer when
>> > using qemu linux-user mode?
>> > At a first glance, I saw in the code that
>> > FBIOGET_FSCREENINFO,=A0FBIOGET_VSCREENINFO and=A0FBIOPUT_VSCR= EENINFO being
>> > declared by couldn't locate where they're handled. Ar= e these hooked to
>> > the
>> > SDL back-end?
>>
>> SDL is only used for system emulation. It should be possible to ad= d
>> 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 wo= uld
>> be the use case for this?
>
>

--001485f89a3c4e1bd9048fda060e--