I didn't realize there was also the menu problem. Does this also happen when you're in fullscreen?
I mainly use Qemu/AmigaOs4.1 in full screen because it gives me a better experience. When I use AmigaOs4.1 I don't want to be disturbed by my host system or be reminded that I am still in emulation
Since you ask me that, I assume that there are no problems in windowed mode, but I haven't tested it yet.
I tested both fullscreen and windowed mode and I don't have your problem. Can you make a video?
To understand the problem I have recorded a video...here you can clearly see the problems, via the title bar of AmigaOs4.1 it is still possible to call up the menus, but you are not allowed to move the mouse pointer to the edge of the screen. I am not sure if the problem can be solved....but see for yourself...
In fullscreen it should never happen. It is behaving as if it were window mode and the AmigaOS window ended one line before the screen border. I tried both on my laptop screen and on an external 4k monitor and in fullscreen I can reach the edge without the host cursor appearing. What options do you use to launch QEmu?
@Maijestro This looks more related to QEMU display backend than to guest side driver. You could try with -display sdl to cross check if it happens with that too or only with -display cocoa. Is it with recent macOS full screen patches or with QEMU master? If it's related to the changes in cocoa backend you could ask on the QEMU mailing list cc-ing Akihiko Odaki (the patch author) but first check with -display sdl and using QEMU master without other patches.
Ok, it is clearly due to the Display Manager Cocoa with the output SDL there are no problems and your driver does what it should.
Balaton I am using Qemu Master without the fullscreen Cocoa patch from Akihiko Odaki, I am not sure if the patch has made it into the Master sources yet as there were changes made by Peter Maydell shortly after the last series.
It seems that Akihiko Odaki's patch series is still not included in Qemu Master, so I added the patch series again. With the last patch series of Akihiko Odaki version 12 it works as under the SDL output. Thanks for the tip.
@AlfredOne
Thanks for this driver and the support of the tablet HID device it works What is of course missing is support for the mouse scroll wheel.
@Maijestro OK then it should be resolved with Akihiko Odaki's series. I think it was reviewed by Peter already but not yet merged. There's still 1-2 weeks until the freeze for QEMU 9.0 starts so it should be in a pull request by then. Since Peter Maydell is one of the master maintainers the right people already know about this series so likely it will be in 9.0 so just wait for it to land in master then.
I think @AlfredOne wrote before that QEMU's tablet should have a wheel but maybe the driver does not support it. But as I said you probably won't see much difference with the sm501 device that does not have host side hardware cursor support so this may only be good for preparation when some other graphics drivers would become available in the future.
I'll add wheel support as soon as I find some free time tonight and send you the updated hidtablet.usbfd driver here. then I thought of integrating the code into the hidtouch.usbfd driver which will thus manage tablet devices as well as touchscreens.
I'll add wheel support as soon as I find some free time tonight and send you the updated hidtablet.usbfd driver here. then I thought of integrating the code into the hidtouch.usbfd driver which will thus manage tablet devices as well as touchscreens.
That's great! Thank you very much, that's very kind of you. Unfortunately I don't have a laptop and can only test your driver with the mouse, but as mentioned before, it works very well now. Apart from the missing mouse wheel support.
@Maijestro It does not matter what's your host pointing device. The driver in the guest only sees the emulated tablet or mouse and should drive that. It does not know where the events come from on the host OS so even if you have a mouse but use -device usb-tablet the guest will see a tablet. The difference between usb-mouse and usb-tablet is that mouse sends relative move coordinates (e.g. x: +5, y: -2) while tablet sends absolute values (x: 1012, y: 44) so with usb-mouse the guest calculates the position which may be affected by mouse acceleration settings in Prefs and could get out of sync with the host pointer while with a tablet the position is given so the pointer will be where it should be.
It does not matter what's your host pointing device. The driver in the guest only sees the emulated tablet or mouse and should drive that. It does not know where the events come from on the host OS so even if you have a mouse but use -device usb-tablet the guest will see a tablet. The difference between usb-mouse and usb-tablet is that mouse sends relative move coordinates (e.g. x: +5, y: -2) while tablet sends absolute values (x: 1012, y: 44) so with usb-mouse the guest calculates the position which may be affected by mouse acceleration settings in Prefs and could get out of sync with the host pointer while with a tablet the position is given so the pointer will be where it should be.
I already understood that and AlfredOne had already explained it. Because it means that the mouse pointer of the host and guest are synchronized with the driver and there are no differences. This is exactly the reason why I welcome this driver. And if it already solves future problems I am of course glad that someone has written it for Qemu/AmigaOs4.1 and we can use it as an alternative.
@all The driver is ready: - added wheel support - added more checks to prevent it from taking control of devices that are already managed well by hid.usbfd.
I can't upload here. Anyone interested, can pm me their email, and I will send the driver. Note: this is a temporary driver to better use QEMU tablet device, but should work with similar devices. The ultimate goal is to integrate everything into hidtouch.usbfd (only the part that is not yet managed in hid.usbfd).
I have tested your driver version 0.9 and it works very well under AmigaOs4.1. Host and guest mouse pointer are exactly the same in movement and also the mouse wheel can be used now. Thank you very much.
What I have noticed, however, is that the first time I use AmigaOs4.1 the host mouse pointer is displayed.....as soon as I make an entry with the mouse, the guest takes over. This only happens at the first start of AmigaOs4.1. If I reboot within the session there are no problems, I think it is because the driver is initialized the first time?
Also I had an older Qemu GL build where I had problems with mouse input slowdown, again no more problems as soon as I use "-device usb-tablet" as input device and host and guest mouse are in sync.
As usual, the video is for demonstration purposes only and I will remove it later so as not to slow down the thread
I finally got a chance to try it out myself. I had to delete the usb touch device in order to get it to work. With that gone, it works well. I can finally use QEMU with the VirtioGPU driver in full-screen mode.** Up till now I've had to put up with running the emulator in a window.
Thanks for getting this up and running.
Hans
** A scaled screen doesn't work in plain mouse mode, because QEMU currently can't handle the VirtioGPU mouse with a scaled screen.
What I have noticed, however, is that the first time I use AmigaOs4.1 the host mouse pointer is displayed.....as soon as I make an entry with the mouse, the guest takes over.
This also seems like a different behavior of the host window manager. It starts sending events to AmigaOS only when the QEMU screen acquires focus with the first click. If I instead launch in fullscreen, QEMU acquires focus directly and the guest cursor starts working immediately.
p.s.: Where did you find the startup audio? It's wonderful. I want it.
This also seems like a different behavior of the host window manager. It starts sending events to AmigaOS only when the QEMU screen acquires focus with the first click. If I instead launch in fullscreen, QEMU acquires focus directly and the guest cursor starts working immediately.
I checked it with the Display Manager SDL and you are right, there are no problems. I am currently running Qemu with the display manager option "-display cocoa,zoom-to-fit=on,full-screen=on". "zoom-to-fit" should not normally be necessary as this option to scale or stretch the image to full screen is normally handled by the graphics card or driver. When the Virtio GPU/drivers are available at some point this problem could also be solved.
If I completely omit the display option "zoom-to-fit", there are no problems with the Display Manager Cocoa either. Maybe I will report the problem anyway. Thanks again for this AmigaOs4.1 driver.
Quote:
p.s.: Where did you find the startup audio? It's wonderful. I want it.
I noticed something else and that is that "-device usb-tablet" does not support 360 degree rotation but only 180 degrees, but I'm not sure if it's the "-device usb-tablet" in general or if your driver doesn't support it under AmigaOs4.1.
I noticed this when I played Quake2 under AmigaOs4.1, I tested it with Display Manger SDL/Cocoa.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
