qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] display: stop using DT_NOGRAPHIC, use DT_NONE


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] display: stop using DT_NOGRAPHIC, use DT_NONE
Date: Tue, 16 Jul 2013 12:35:45 +0100

On 10 July 2013 06:08, Michael Tokarev <address@hidden> wrote:
> I updated the git branch on my site --
>
>  http://git.corpit.ru/?p=qemu.git;a=shortlog;h=refs/heads/mjt-dt-nographic
>
> (two patches on the top).  This now includes the `make check' fix by
> flipping the check (FW_CFG_NOGRAPHIC==1 vs ==0), more documentation
> rewording (suggested by Peter) and Reviewed-by tags.
>
> And yes, I dislike this mess too -- neither -nographic nor -display none
> should be tied with guest serial port.  Better approach for the Ctrl+C
> handling has been proposed by pbonzini. Better suggestions for 
> FW_CFG_NOGRAPHIC
> welcome.  Maybe something like -serial-console (linux has console=ttyS0,tty1)
> which will be turned on by -nographic and which will be passed to firmware
> as FW_CFG_NOGRAPHIC, and which can be used in -serial none case to check for
> sanity.  But actually, -display none isn't that bad of a choice here (and
> maybe we may also enforce non-none serial in case of -display none).

I think "-display none" should just mean "I didn't plug the monitor in":
it should have no effect at all on the guest (or on the way we emulate
or configure any other of our devices) -- it's just that graphics output
doesn't go anywhere. So the test case is correct (the test was started
with '-display none' and this shouldn't result in the FW_CFG_NOGRAPHIC
bit being set) and we need to make QEMU behave correctly (ie by tying
that FW_CFG_ setting to something other than display=none).

On a similar line of thought:
* milkymist_tmu2_create() should definitely not be doing the X probing
  if DT_NONE, but it should ideally still create the milkymist-tmu2 device.
  This is hard though because the device itself basically assumes it can
  use all the OpenGL APIs. So I think the change in your patch is as
  good as we're going to get.
* I'm not convinced we should need to disable the sparc keyboard
  if DT_NONE -- shouldn't this just work as if you had a physical
  keyboard plugged in but never typed anything on it? (Or does
  real hardware use "keyboard plugged in" to decide something?)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]