@Maijestro

Ok, I will try. In any case, @Hans is certainly right. A tablet with absolute coordinates is not suitable for controlling a rotation. Absolute coordinates have left and right bounds, and rotation is likely mapped absolutely to -90 degrees on the left and +90 degrees on the right.
A mouse, on the other hand, only indicates relative movements, so it allows you to rotate without limits in both directions.

@Maijestro

I can't run Quake2 on QEmu.
If i try, i get the message "Error: Couldn't create window".

I have:
- minigl.library v2.24
- Warp3D.library 53.27

Where am I doing wrong?

@Maijestro

Quote:

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.

@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'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.

@Maijestro

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
I tested both fullscreen and windowed mode and I don't have your problem. Can you make a video?

@Maijestro

I didn't realize there was also the menu problem.
Does this also happen when you're in fullscreen?

@Maijestro

The 2 mouse cursors, host and guest, visible at the same time, I think are inevitable.
In "tablet" mode, as soon as the cursor leaves the emulated AmigaOS screen, the host cursor appears, but the Amiga cursor no longer receives events and remains stationary in the last position.

@Maijestro

The difference is how QEMU emulates a pointing device.
Normally QEMU shows a touchpad or a mouse as a standard HID mouse, so AmigaOS4.1 sees a HID mouse and receives from QEMU events with relative movements in x and y. In this case the official hid.usbfd driver of amigaos handles this in the right way.
You can verify that events received are relative x,y by looking at the mouse cursor positions in the emulated AmigaOS4.1 and the "real" mouse cursor of the host system: they do not match. In general it is not a problem, except in particular cases (see Hans's post).

Alternatively, QEMU can emulate the pointing device as a HID tablet instead of a HID mouse. In this case, QEMU does not expose a mouse, but exposes a tablet as an input device and sends absolute coordinates to AmigaOS4 such that the AmigaOS4 mouse cursor coincides with the host operating system's mouse cursor. Hans reported that this mode would be useful when using the Virtio GPU device.
The problem is that the amigaos hid.usbfd driver cannot currently manage the tablet device.

So I wrote a driver that handles a tablet device.
Using the HID protocol, this driver can actually manage all tablet like devices, but I was wondering if it wasn't worth making the driver more selective, so that it works only when it detects the QEMU emulated tablet.

@vagappc

sketchblock reads pressure.

If anyone has a touch device (graphic tablet, touchpad, etc..) that doesn't work on AmigaOS4, they can report it here and we'll evaluate whether it's possible to add support in one of my drivers.

@vagappc
Yes. Can you tell me the graphics tablet model?
Write me privately or in the new topic:
Support for other touch devices.

@all
Do you think it would be useful if I released a QEMU specific usb driver (e.g. qemutatablet.usbfd or qemu.usbfd), instead of a generic hid driver that handles qemu but could handle other hid devices?

@hans

Hi Hans,
try if the attached driver is right for you.

Quick explanation:
this driver should recognize and handle the QEMU Tablet Device and similar.
It does not require touch.device or touchbench, it is a standalone driver that sends NEWPOINTERPOS/TABLET events to the input.device, so it works with absolute coordinates.

I tried it with QEMU and the option and it seems to work.

Note: being a fast adaptation, the driver could also take control of other similar devices and bypass the official AmigaOS4 hid.usbfd driver. If this causes you problems let me know and I will make the driver more selective.

Best regards!

Attach file:

---

Link only for registered users

@AmigaSociety

This is what i've done to be able to use 2560x1440 on my X1000 withe a RadeonHD card.

Instead, with the Radeon RX550 I tried to insert all the possible resolutions with all the possible frequencies, but it doesn't engage any screenmode beyond fullHD 1920x1080.

note: The monitor supports resolutions up to 3840x1600.

@balaton
@hans
I checked the hid report buffer of the QEMU USB Tablet device.
It is described as a Mouse, with 3 buttons, a wheel and absolute X,Y coordinates.
For this reason it is not managed by the hidtouch.usbfd, it is not seen as a touchscreen.

In any case the QEMU Tablet device seems to me to be a simulation of a mouse by QEMU. I could easily add support for this type of device, but it makes more sense for the AmigaOS4 hid.usbfd driver to handle it directly. Maybe it doesn't handle it because it only recognizes mice with relative coordinates or touchscreen/digitizer with absolute coordinates.

@hans, have you tried to see if the touchscreen of the tablet is seen as a USB device with the 'lsusb' command?

As you can imagine from the title, here we will try to solve the problems related to the QEMU's USB Tablet device.

@Hans

As stated by Graff, the logs indicate an HID device.
So it should be handled by the hid.touch driver.
You could try this, in case it's just a recognition problem at boot:
try launching "USBCtrl restart" and see if the device appears in TouchPrefs.

If it doesn't work like that either, we should do a bit of debugging to understand if the hid device is a touchscreen type or if it is a different type and therefore is not recognized by the hid.touch.

p.s.: Have you checked whether the device appears in the TouchPrefs device list?

I tested the following 3 configurations:

1) 1x2GB DIMM on Slot1

CFE relevant output:



2) 2x2GB DIMM on Slot1 & Slot2

CFE relevant output:



3) 2x2GB DIMM on Slot1 & Slot3

CFE relevant output:



RageMem results:

1)
---> RAM <---
READ32: 2822 MB/Sec
READ64: 4049 MB/Sec
WRITE32: 2374 MB/Sec
WRITE64: 2284 MB/Sec
WRITE: 340 MB/Sec (Tricky)

2)
---> RAM <---
READ32: 2837 MB/Sec
READ64: 4077 MB/Sec
WRITE32: 2387 MB/Sec
WRITE64: 2295 MB/Sec
WRITE: 339 MB/Sec (Tricky)

3)
---> RAM <---
READ32: 2827 MB/Sec
READ64: 3961 MB/Sec
WRITE32: 2725 MB/Sec
WRITE64: 3252 MB/Sec
WRITE: 344 MB/Sec (Tricky)


Indeed, configuration 3 shows more writing speed, in tests where caches do not come into play.

RageMem: WRITE64 test:
Interleaved: 3252 MB/Sec
Not Interleaved: 2295 MB/sec

Stream_memspeed: Write test (memset 750 0 - only blocks >= 5MB)
Interleaved: 3363 MB/Sec
Not Interleaved: 2290 MB/sec

Thanks everyone for the contribution.