Re: [Qemu-devel] Qemu SDL2 bug

2018-02-20 Thread Howard Spoelstra
On Tue, Feb 20, 2018 at 10:52 AM, Gerd Hoffmann  wrote:
>> Hi,
>>
>> I went on to compile dgibson's rep which includes that commit. But the
>> issue remains.
>> I normally use -usb-mouse -usb-kbd in the command line, as these work
>> for Mac OS 9.x up to 10.5. Using -usb-tablet allows the mouse to
>> travel outside the GUI and seems to circumvent the issue in OSX
>> guests, but Mac OS 9.x  guests do not work with -usb-tablet.
>
> can you try
> https://www.kraxel.org/cgit/qemu/log/?h=sirius/sdl2-hotkey-keyup
> ?
>
> cheers,
>   Gerd
>

Hi Gerd,

Perfect! That patch fixes the issue.

Thanks,
Howard



Re: [Qemu-devel] Qemu SDL2 bug

2018-02-20 Thread Gerd Hoffmann
> Hi,
> 
> I went on to compile dgibson's rep which includes that commit. But the
> issue remains.
> I normally use -usb-mouse -usb-kbd in the command line, as these work
> for Mac OS 9.x up to 10.5. Using -usb-tablet allows the mouse to
> travel outside the GUI and seems to circumvent the issue in OSX
> guests, but Mac OS 9.x  guests do not work with -usb-tablet.

can you try
https://www.kraxel.org/cgit/qemu/log/?h=sirius/sdl2-hotkey-keyup
?

cheers,
  Gerd




Re: [Qemu-devel] Qemu SDL2 bug

2018-02-20 Thread Gerd Hoffmann
  Hi,

> > Including most recent ui pull request (commit 
> > 5e8d6a12d643a38b82a0a713a77d1192117dbdca) ?
> >
> > I'm wondering that you need Ctrl-Alt-G in the first place, sdl2 and gtk
> > should have identical behavior here (i.e. no ctrl-alt-g needed in case a
> > tablet or other absolute ptr device is present).
> >
> > cheers,
> >   Gerd
> >
> Hi,
> 
> I went on to compile dgibson's rep which includes that commit. But the
> issue remains.
> I normally use -usb-mouse -usb-kbd in the command line, as these work
> for Mac OS 9.x up to 10.5. Using -usb-tablet allows the mouse to
> travel outside the GUI and seems to circumvent the issue in OSX
> guests, but Mac OS 9.x  guests do not work with -usb-tablet.

Ok, I'll try to figure what is going on.

But without usb-tablet both sdl and gtk should grab the mouse and
require ungrab via ctrl-alt-g hotkey to move it out of the window ...

cheers,
  Gerd




Re: [Qemu-devel] Qemu SDL2 bug

2018-02-19 Thread Howard Spoelstra
On Mon, Feb 19, 2018 at 11:30 AM, Gerd Hoffmann  wrote:
>> >> Hi,
>> >>
>> >> With SDL, unlike GTK, the mouse does not move outside the window. So I
>> >> have to use Ctrl-Alt-G to release focus and then click in the other
>> >> window. After two switches the reported issue occurs. Indeed, the Alt
>> >> key seems to go into a state in which it is stuck. When trying to
>> >> exclude my own keyboard being at fault, I've also noticed the right
>> >> Alt key on my keyboard cannot be used for the release.
>> >
>> > Which qemu version?  There have been a bunch of SDL2 fixes in the 2.12
>> > devel cycle already, so if you are on 2.11 still please try git master
>> > and see whenever that improves things.
>> >
>> > cheers,
>> >   Gerd
>> >
>>
>> Hi.
>>
>> This was with my own qemu master builds as of yesterday.
>
> Including most recent ui pull request (commit 
> 5e8d6a12d643a38b82a0a713a77d1192117dbdca) ?
>
> I'm wondering that you need Ctrl-Alt-G in the first place, sdl2 and gtk
> should have identical behavior here (i.e. no ctrl-alt-g needed in case a
> tablet or other absolute ptr device is present).
>
> cheers,
>   Gerd
>
Hi,

I went on to compile dgibson's rep which includes that commit. But the
issue remains.
I normally use -usb-mouse -usb-kbd in the command line, as these work
for Mac OS 9.x up to 10.5. Using -usb-tablet allows the mouse to
travel outside the GUI and seems to circumvent the issue in OSX
guests, but Mac OS 9.x  guests do not work with -usb-tablet.

Best,
Howard



Re: [Qemu-devel] Qemu SDL2 bug

2018-02-19 Thread Gerd Hoffmann
> >> Hi,
> >>
> >> With SDL, unlike GTK, the mouse does not move outside the window. So I
> >> have to use Ctrl-Alt-G to release focus and then click in the other
> >> window. After two switches the reported issue occurs. Indeed, the Alt
> >> key seems to go into a state in which it is stuck. When trying to
> >> exclude my own keyboard being at fault, I've also noticed the right
> >> Alt key on my keyboard cannot be used for the release.
> >
> > Which qemu version?  There have been a bunch of SDL2 fixes in the 2.12
> > devel cycle already, so if you are on 2.11 still please try git master
> > and see whenever that improves things.
> >
> > cheers,
> >   Gerd
> >
> 
> Hi.
> 
> This was with my own qemu master builds as of yesterday.

Including most recent ui pull request (commit 
5e8d6a12d643a38b82a0a713a77d1192117dbdca) ?

I'm wondering that you need Ctrl-Alt-G in the first place, sdl2 and gtk
should have identical behavior here (i.e. no ctrl-alt-g needed in case a
tablet or other absolute ptr device is present).

cheers,
  Gerd




Re: [Qemu-devel] Qemu SDL2 bug

2018-02-19 Thread Howard Spoelstra
On Mon, Feb 19, 2018 at 9:56 AM, Gerd Hoffmann  wrote:
> On Mon, Feb 19, 2018 at 08:58:51AM +0100, Howard Spoelstra wrote:
>> On Mon, Feb 19, 2018 at 8:09 AM, Thomas Huth  wrote:
>> > On 18.02.2018 11:11, Howard Spoelstra wrote:
>> >> Hi,
>> >>
>> >> I'd like to report a bug when using the SDL2 GUI in both Linux and
>> >> Windows, which can be observed with in my case latest qemu-system-ppc
>> >> running parallel instances of OSX 10.4 and 10.3.
>> >>
>> >> After switching back and forth between GUIs, dragging becomes copying,
>> >> keyboard starts using a strange character set.
>> >> An additional "Alt" key press is needed to restore normal behaviour.
>> >
>> >  Hi,
>> >
>> > how do you switch back and forth between GUIs? Using the mouse or a
>> > keystroke? I guess the latter ... sounds like the Alt key could be
>> > "stuck" in the guest?
>> >
>> >  Thomas
>>
>> Hi,
>>
>> With SDL, unlike GTK, the mouse does not move outside the window. So I
>> have to use Ctrl-Alt-G to release focus and then click in the other
>> window. After two switches the reported issue occurs. Indeed, the Alt
>> key seems to go into a state in which it is stuck. When trying to
>> exclude my own keyboard being at fault, I've also noticed the right
>> Alt key on my keyboard cannot be used for the release.
>
> Which qemu version?  There have been a bunch of SDL2 fixes in the 2.12
> devel cycle already, so if you are on 2.11 still please try git master
> and see whenever that improves things.
>
> cheers,
>   Gerd
>

Hi.

This was with my own qemu master builds as of yesterday.

Best,
Howard



Re: [Qemu-devel] Qemu SDL2 bug

2018-02-19 Thread Gerd Hoffmann
On Mon, Feb 19, 2018 at 08:58:51AM +0100, Howard Spoelstra wrote:
> On Mon, Feb 19, 2018 at 8:09 AM, Thomas Huth  wrote:
> > On 18.02.2018 11:11, Howard Spoelstra wrote:
> >> Hi,
> >>
> >> I'd like to report a bug when using the SDL2 GUI in both Linux and
> >> Windows, which can be observed with in my case latest qemu-system-ppc
> >> running parallel instances of OSX 10.4 and 10.3.
> >>
> >> After switching back and forth between GUIs, dragging becomes copying,
> >> keyboard starts using a strange character set.
> >> An additional "Alt" key press is needed to restore normal behaviour.
> >
> >  Hi,
> >
> > how do you switch back and forth between GUIs? Using the mouse or a
> > keystroke? I guess the latter ... sounds like the Alt key could be
> > "stuck" in the guest?
> >
> >  Thomas
> 
> Hi,
> 
> With SDL, unlike GTK, the mouse does not move outside the window. So I
> have to use Ctrl-Alt-G to release focus and then click in the other
> window. After two switches the reported issue occurs. Indeed, the Alt
> key seems to go into a state in which it is stuck. When trying to
> exclude my own keyboard being at fault, I've also noticed the right
> Alt key on my keyboard cannot be used for the release.

Which qemu version?  There have been a bunch of SDL2 fixes in the 2.12
devel cycle already, so if you are on 2.11 still please try git master
and see whenever that improves things.

cheers,
  Gerd




Re: [Qemu-devel] Qemu SDL2 bug

2018-02-18 Thread Howard Spoelstra
On Mon, Feb 19, 2018 at 8:09 AM, Thomas Huth  wrote:
> On 18.02.2018 11:11, Howard Spoelstra wrote:
>> Hi,
>>
>> I'd like to report a bug when using the SDL2 GUI in both Linux and
>> Windows, which can be observed with in my case latest qemu-system-ppc
>> running parallel instances of OSX 10.4 and 10.3.
>>
>> After switching back and forth between GUIs, dragging becomes copying,
>> keyboard starts using a strange character set.
>> An additional "Alt" key press is needed to restore normal behaviour.
>
>  Hi,
>
> how do you switch back and forth between GUIs? Using the mouse or a
> keystroke? I guess the latter ... sounds like the Alt key could be
> "stuck" in the guest?
>
>  Thomas

Hi,

With SDL, unlike GTK, the mouse does not move outside the window. So I
have to use Ctrl-Alt-G to release focus and then click in the other
window. After two switches the reported issue occurs. Indeed, the Alt
key seems to go into a state in which it is stuck. When trying to
exclude my own keyboard being at fault, I've also noticed the right
Alt key on my keyboard cannot be used for the release.

Best,
Howard



Re: [Qemu-devel] Qemu SDL2 bug

2018-02-18 Thread Thomas Huth
On 18.02.2018 11:11, Howard Spoelstra wrote:
> Hi,
> 
> I'd like to report a bug when using the SDL2 GUI in both Linux and
> Windows, which can be observed with in my case latest qemu-system-ppc
> running parallel instances of OSX 10.4 and 10.3.
> 
> After switching back and forth between GUIs, dragging becomes copying,
> keyboard starts using a strange character set.
> An additional "Alt" key press is needed to restore normal behaviour.

 Hi,

how do you switch back and forth between GUIs? Using the mouse or a
keystroke? I guess the latter ... sounds like the Alt key could be
"stuck" in the guest?

 Thomas



[Qemu-devel] Qemu SDL2 bug

2018-02-18 Thread Howard Spoelstra
Hi,

I'd like to report a bug when using the SDL2 GUI in both Linux and
Windows, which can be observed with in my case latest qemu-system-ppc
running parallel instances of OSX 10.4 and 10.3.

After switching back and forth between GUIs, dragging becomes copying,
keyboard starts using a strange character set.
An additional "Alt" key press is needed to restore normal behaviour.

Best regards,
Howard