> I don't see how this "rules out real mode switch". Clearly, the driver
> for the card determines which method is used to switch modes, which in
> turn will depend on the hardware that you're using. If one model of
card
> supports switching inside the driver, and another requires calling the
> BIOS, then you're going to call the BIOS in the second case, but not
in
> the first one.
Good point - I missed it.
> But you just said that the "SDL map a BMP to full-screen" also doesn't
> work? So it's not a "virtual frame-buffer" problem?
Full screen map does not work if I am using on-boards graphics chip. It
seems to work with only certain cards/drivers (like the Stealth PCI
card). I am almost sure it is not a virtual frame buffer problem at this
time. I am tracing through the code step by step to figure out where it
is crashing ...
Thanks
Jayant
-----Original Message-----
From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
Sent: Thursday, May 31, 2007 2:55 PM
To: Jayant Mangalampalli; xen-devel@xxxxxxxxxxxxxxxxxxx
Cc: Anantharamaiah Bhaskara
Subject: RE: [Xen-devel] X11_EnterFullScreen fails
> -----Original Message-----
> From: Jayant Mangalampalli [mailto:Jayant_Mangalampalli@xxxxxxxxxxx]
> Sent: 31 May 2007 10:09
> To: Petersson, Mats; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Anantharamaiah Bhaskara
> Subject: RE: [Xen-devel] X11_EnterFullScreen fails
>
> We are currently using AMD Sahara board (with on board ATI graphics
> chip) and could never get the full screen to work. We tried using MSI
> video card (that plugs into AGP slot) and could not get full screen to
> work there too. However, when we switched to Diamond's Stealth 3D 2000
> Pro video card (that plugs into PCI slot), we could get the
> full screen
> to work. Moreover, to rule out "real mode switch"
> possibility, we built
> and ran a user level application that leverages X11 drivers
> through SDL
> to map a BMP image on full screen.
I don't see how this "rules out real mode switch". Clearly, the driver
for the card determines which method is used to switch modes, which in
turn will depend on the hardware that you're using. If one model of card
supports switching inside the driver, and another requires calling the
BIOS, then you're going to call the BIOS in the second case, but not in
the first one.
The only way to know which is used for sure is by tracing the entire
call for "fullscreen" mode to see where it ends up.
> The results are exactly the same on
> target as they are with xen's guest domain - full screen does not work
> with on boards graphics chip, does not work with MSI card in the AGP
> slot, but works with Stealth in PCI slot.
So, the problem has nothing to do with Xen, right? It's just the drivers
for ATI and MSI (whatever model of chip this contains) that aren't able
to do the full-screen switch for one reason or another.
>
> Is anybody aware of issues with onboard ATI graphics chip that could
> prevent guest virtual frame buffer not to span full-screen?
But you just said that the "SDL map a BMP to full-screen" also doesn't
work? So it's not a "virtual frame-buffer" problem? Or did I miss
something? I am 99.9% sure that it's not the graphics chip itself - it
doesn't care one least bit about what you're drawing on the screen - it
just copies pixels from a memory region to a RAMDAC, which combined with
some sync signals makes the display - it doesn't really matter if those
pixels are characters in VGA text mode or 1280 x 1024, 32bpp @ 80Hz.
[Ok, text mode works via a lookup buffer to make pixels from a
font-table, but still, the graphics chip itself can handle it].
Full-screen mode isn't any different from the normal X11 mode that
you're using (unless of course you're using a different number of bits
per pixel for example - there may be "holes" in the list of supported
resolutions at different bpp).
--
Mats
>
> Thanks
> Jayant
>
> -----Original Message-----
> From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
> Sent: Wednesday, May 30, 2007 10:01 PM
> To: Jayant Mangalampalli; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] X11_EnterFullScreen fails
>
> > -----Original Message-----
> > From: Jayant Mangalampalli
> [mailto:Jayant_Mangalampalli@xxxxxxxxxxx]
> > Sent: 30 May 2007 17:23
> > To: Petersson, Mats; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] X11_EnterFullScreen fails
> >
> > If this is the case, though, why does only full-screen mode
> fail? Why
> > not the normal non-full-screen mode?
> >
> > -----Original Message-----
> > From: Jayant Mangalampalli
> > Sent: Wednesday, May 30, 2007 9:51 PM
> > To: 'Petersson, Mats'; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] X11_EnterFullScreen fails
> >
> > Highly likely. Unfortunately we cannot salvage any data
> during crash.
> > But I think this is a great pointer, especially since I am
> also facing
> > problems trying to get TinyX to start in the graphics mode - but the
> > vesafb driver tries to access the BIOS and it fails for
> > exactly the same
> > reason (it is in protected mode by that time). The result
> is, however,
> > not a crash but a flimsy looking "text mode" like screen.
>
>
> Well, I don't really know the answer. But I used to work on Windows
> graphics drivers, and I know that sometimes switching the display mode
> will incur a BIOS call (I never quite understood when this
> was and when
> it wouldn't happen - I think it depends on several things,
> including the
> driver-code itself which may support some modes and say "I don't care
> about supporting this mode" - at which point the OS would call the
> BIOS[1] code to attempt it that way). Non-full-screen mode doesn't
> require BIOS calls, for the obvious reason that the graphics
> mode isn't
> being changed then - full-screen mode may well switch from the current
> display mode to a different display-mode even if it's the same
> resolution, e.g. 16bits per pixel or 8 bits per pixel, just as an
> example.
>
> Also, is the SDL screen in text or graphical mode when you switch to
> full-screen? If it's in text-mode, then it's 99% sure that the BIOS is
> involved.
>
> I'm not saying this IS what happens, just that it's something to
> investigate.
>
> You may be able to capture more of the trace-back if you use serial
> console either from Linux or the hypervisor, and if it's
> hypervisor that
> crashes [and you don't use serial console] you may get more info by
> "noreboot" on the "xen" line in your grub.conf (or similar).
>
> [1] BIOS = VGA-BIOS, not the "start my PC BIOS".
>
> --
> Mats
>
> >
> > Thanks
> > Jayant
> >
> > -----Original Message-----
> > From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
> > Sent: Wednesday, May 30, 2007 9:38 PM
> > To: Jayant Mangalampalli; xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-devel] X11_EnterFullScreen fails
> >
> >
> >
> > > -----Original Message-----
> > > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > > Jayant Mangalampalli
> > > Sent: 30 May 2007 17:05
> > > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: [Xen-devel] X11_EnterFullScreen fails
> > >
> > > I am trying to set the guest window to full-screen mode but
> > > the domain consistently crashes when I try to do that. The
> > > problem could be traced to a point where X11-driver used by
> > > SDL itself fails. Here is the call trace before system
> > > crashes (most recent call last):
> > >
> > > SDL_video.c::SDL_SetVideoMode() makes a call to
> > > video->SetVideoMode(). (We use X11 video driver)
> > >
> > > video->SetVideoMode() = SDL_x11video.c::X11_SetVideoMode()
> > >
> > > The above makes a call to SDL_x11video.c::X11_ResizeWindow()
> > > which makes a call to X11_EnterFullScreen() (in SDL_x11modes.c)
> > >
> > > X11 does support full-screen mode and I am unable to
> > > understand why it is initiated by xen. Has anyone tried this?
> >
> > What's the crash symptoms? Is it possible that the X11 driver
> > is calling
> > the BIOS, and that this fails in Xen due to restrictions on running
> > real-mode, which doesn't happen in native mode?
> >
> > --
> > Mats
> > >
> > > Thanks,
> > >
> > > Jayant Mangalampalli
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home