Re: [Qemu-devel] quick gtk2.c update

["Jim C. Brown" <jma5@umd.edu>]

On Mon, Jun 27, 2005 at 12:11:10PM -0500, jeebs@yango.us wrote:
> >
> > This should be fixed now. (At least, this now works in Windows 98 and XP.) 
> > I
> > managed to combine the 3 separate mouse handlers into a single function as 
> > well,
> > so there is less redundant code.
> 
> It does appear to be fixed.
> 

Excellent.

> > Also, I managed to get rid of the all of the GTK warnings.
> 
> That's always good.  Although this time I didn't watch it build to see if 
> there were any new ones.
> 

I meant the GTK warnings that appear at run time (the "assert failed" warnings).
I've never gotten GTK warnings when building a working version...but I've never
built under Windows either.

> 
> There *is* still an <insert> key problem.
> 
> I tested it under Win3, Win95 and Win98
> 
> That's the only key I've noticed that still has problems.  But I may not 
> have tested them all, so I might have missed one or two others.
> 

Did you test with Windows 98SE?

Windows 98SE has no issues with the insert key when running under GTK in Linux..
which would mean the problem is with VK_INSERT.

> 
> When I run the gtk version from the qgui program (which just lets you select 
> which VM, what options etc., and then runs it) the qemu window doesn't pop 
> up as visible.  I have to clcik on its title on the task bar to bring it 
> forward.  Probably needs a command to bring it into 'focus' or some such.
> 
> > Most fullscreen glitches are gone now. (The only one left is that, if you 
> > change

I should have been clearer.

The glitches that I fixed were for the Xvid fullscreen driver. Windows build
still uses the null fullscreen driver.

> 
> I haven't really tested that much...
> 
> Okay, it looks like the full screen mode has problems.
> 
> First, it doesn't really go 'full screen'.  It just makes a borderless 
> window.
> 

Thats to be expected with the null fullscreen driver. qemu's GTK support
expects the fullscreen driver to change the resolution of the host to match
that of the guest (that way the window will take up the entire screen).

I'm working on an SDL fullscreen driver, but it is uglier. (It'd require
usurping the internal DisplayState structure and replace the GTK routines with
custom SDL versions for the duration of fullscreen mode Exiting fullscreen mode
would then have to restore the GTK routines. Not to mention syncing the 2
frame buffers between switches.)

> That means you can't use a guest window the same size as the host, otherwise 
> the host XP toolbar will cover up part of the guest window.  (XP's toolbar 
> can be on any side of the screen.  There can even be multiple toobars.  So 
> you really can't depend on having any certain amount of visible screen 
> available.)
> 

I never thought about that. Does the XP toolbar show up when using SDL's
fullscreen mode?

> As a test, I decided to see what would happen if I made Win98's screen 
> larger than what my real one is.  The results were interesting!
> 
> The interesting part was the mouse behavior!  I ended up with *two* mouse 
> cursors on the screen. 

That is weird. I've seen that once before, when the pointer grab failed (because
the host pointer was outside the GTK window) but then GDK later grabbed it
anyways. When it did the grab, it failed to render the host pointer invisible.
The effect was a "swirling mouse" in the middle of the guest screen.

> And they weren't moving quite right.  I couldn't 
> move the guest Win98 one where I needed to.
> 

This is expected behavior. Currently the GTK code assumes that the entire window
fits in a single screen. When it grabs the mouse (and after it renders the mouse
invisible), it confines the pointer to an area in the very middle of the window
that is approximately half the size of the full area of the window. When the
host pointer hits the border of this inner area, it is wrapped to the other
side.

Because the GTK window was larger than the screen, when the host pointer hit the
edge of the screen it wouldn't be able to move any more .. which means the guest
pointer wouldn't be able to either. Even if it was at the top corner of the
window.

> I don't know if this was a gtk issue, or a Windows host issue....
> 

It's really a hack around a GDK limitation.

> This time, I didn't even test the full screen mode (since you said it does 
> still have problems.).  But, I definetly have mouse problems.  After I 
> switched to a screen larger than my real screen, I couldn't move the mouse 
> much.  It was very limited amount of movement.  Much less than the visible 
> part of the qemu screen was.
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.