Headlines |
-
amidisas.tar.bz2 - development/utility
Apr 16, 2024
-
wildmidi.lha - audio/play
Apr 15, 2024
-
liba52.lha - development/library/audio
Apr 14, 2024
-
libcurl.lha - development/library/misc
Apr 14, 2024
-
libopenssl.lha - development/library/misc
Apr 14, 2024
-
bermudasyndrome.lha - game/action
Apr 14, 2024
-
amigagpt.lha - network/chat
Apr 14, 2024
-
curl.lha - network/misc
Apr 14, 2024
-
dgen_sdl.lha - emulation/gamesystem
Apr 12, 2024
-
amiarcadia.lha - emulation/gamesystem
Apr 11, 2024
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home 
|
@balaton Quote: I don't know if this could be an issue with emulation or a bug in AmigaOS. That's certainly possible. However, if real hardware devices are working properly on a real Pegasos-II, but not in QEMU, then it's unlikely (but still possible). Quote: If you can reproduce the same with amigaone then it's more likely to be an issue in QEMU. If only happens on pegasos2 then it may be related to shared interrupts which may not be handled well in AmigaOS according to joerg so it could be a bug in AmigaOS that may need to be fixed to improve this. I'm not convinced that Joerg is correct. After all, real Pegasos-II also shares the same interrupt between multiple devices. If shared interrupts were a problem, then we should see people with real Pegasos-IIs complaining about it. The AmigaOS kernel can definitely handle shared interrupts. Interrupt handlers on the same IRQ number are put in a priority sorted list. Each handler is called one by one, until one of them returns TRUE, indicating that it has processed and acknowledged the interrupt. So long as all handlers in the chain are written properly, everything works fine. It's quite possible for a faulty driver to either return TRUE when the interrupt didn't belong to it, or to fail to acknowledge an interrupt that does belong to it. Either case would cause an instant lockup with level triggered interrupts, because the interrupt line doesn't get cleared until the interrupt is properly acknowledged. Quote: Between 8.2 and 9.0 there were no changes to irq handling on pegasos2 and amigaone so probably it's the same with 8.2.1 but using the latest QEMU version may help to make sure you don't debug something that was already fixed. I'll try updating to v9, and see what happens. Testing the A1-XE version will take more time... Quote: I can't tell from the logs what could this be, I don't know much about PIC or it's emulation in QEMU, ... Yeah, all I have so far is a clear change in behaviour. I haven't managed to track down how the PIC emulation code triggers an interrupt in the emulated PowerPC. That's another potential point at which something could go wrong (I'm guessing that x86/x64 emulation is much more tested than PPC). Quote: Could this be something related to not handling spurious interrupts correctly in AmigaOS? I mean something like described here: https://forum.osdev.org/viewtopic.php?f=1&t=32722 Also in my understanding if multiple devices share an interrupt the interrupt handler should check each possible source and not ack the interrupt if none of the sources have active interrupt to avoid spurious interrupts. No idea. I'll try to see if I can get interrupt related debug output out of the AmigaOS kernel. If the kernel is receiving interrupts after the driver has stopped receiving them. This one problem is turning into a time-sucking rabbit hole... Hans
|
|
|
|
|
|
Re: Qemu Pegasos II interrupts issue
|
|
Home away from home
|
@Joerg
I was thinking of trying the A1-XE emulation instead. The Pegasos-II does indeed share a single IRQ line over multiple devices.
That's just a workaround, though. If there is an IRQ emulation issue, then we want to figure out what it is and get it fixed.
@Maijestro
Did you get any device failure during that time? For example, the ethernet suddenly stops working. What we're looking for is a change in IRQ behaviour when something goes wrong...
@derfs
I'm currently using a self-compiled v8.2.1. No idea if Balaton's IRQ updates are included or not.
Hans
|
|
|
|
|
|
Qemu Pegasos II interrupts issue
|
|
Home away from home
|
I remember some previous discussions about potential problems with the interrupt emulation (at least for the Pegasos-II). Well, I've spotted something in my logs while trying to track down random freezes: Here's a trace when the driver(s) receives an interrupt:
pic_update_irq master 0 imr 45 irr 2 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
The trace above occurs for every received interrupt (although it is different early on). Then, something goes wrong, and I see:
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 1 imr 249 irr 3 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 0 imr 45 irr 128 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
pic_update_irq master 1 imr 249 irr 5 padd 0
Once this new pattern starts, then the drivers no longer get any interrupts. The last thing I see before it goes wrong, is the VirtioGPU driver indicating that the interrupt belongs to another device. Previous instances of the interrupt being passed on to another device cause no trouble, so I'm not sure why it suddenly starts failing. I do know that no more interrupts are received.** Perhaps others could try tracing the IRQ behaviour as well. You need to add the following to the qemu command line: --trace "*update_irq" Hans ** For testing, I put the VirtioGPU's interrupt at the highest priority. So it gets to see all interrupts on the assigned IRQ number, including ones meant for another device. The interrupts stop coming...
|
|
|
|
|
|
Re: Raylib v4.5.0
|
Posted on: 3/12 12:06
#24
|
Home away from home
|
@afxgroup
Thanks. Does your port need your special clib2? Or can it be built with the standard SDK?
Hans
|
|
|
|
|
|
Re: Touchscreen HID driver & QEMU
|
|
Home away from home
|
@Maijestro
You'd probably get the same behaviour with an actual tablet. You can't move your finger beyond the edge of the screen.
A mouse, on the other hand, can keep on giving the computer more "moved x steps to the left/right" all the way to the edge of your desk, and beyond.
Hans
|
|
|
|
|
|
Re: Raylib v4.5.0
|
|
Home away from home
|
@MartinW
Sorry to hear that.
Hans
|
|
|
|
|
|
Re: Raylib v4.5.0
|
|
Home away from home
|
@MartinW Do we have a fully working RayLib port yet? If so, where do we get it from? If it helps, RayLib 5 now has an SDL2 backend for graphics (not for audio, although miniaudio can use SDL2). Hans
|
|
|
|
|
|
Re: Touchscreen HID driver & QEMU
|
|
Home away from home
|
@AlfredOne
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.
|
|
|
|
|
|
Re: Touchscreen HID driver & QEMU's USB Tablet device
|
|
Home away from home
|
@balaton Quote: But you probably won't see any difference with sm501 that's using guest side hw cursor so could only tell if it works at all but not if it's any better than usb-mouse which was the question to be tested. Nope. The QEMU USB tablet device is unusable with the default HID driver. If you can't see any difference between it and a standard USB mouse, then the driver (and QEMU) are doing a very good job. Hans
|
|
|
|
|
|
Re: Touchscreen HID driver & QEMU's USB Tablet device
|
|
Home away from home
|
@AlfredOne Sorry, I haven't had a chance to test your driver. I also think that support for the virtual QEMU tablet device should be in a generic HID driver. @Maijestro Quote: I see it similarly to @Balaton the driver should be developed primarily for real hardware, of course it would be nice if you could extend this driver to support Qemu/AmigaOs4.1. As already mentioned, we cannot reproduce the problems that Hans has with the Virtio GPU and the use of the mouse cursor because these drivers are not available to us. You don't need the VirtioGPU driver to test the QEMU tablet device. Hans
|
|
|
|
|
|
Re: Touchscreen HID driver & QEMU's USB Tablet device
|
|
Home away from home
|
@balaton Quote: I don't know what the usb-tablet device emulates. It seems like a HID device that reports absolute coordinates. It usually works with other guest OS drivers but don't know what the AmigaOS driver supports. It looks like the AmigaOS HID driver doesn't support it (I tried it out, and it didn't work). Not surprising, as we've never had such a device. Quote: An alternative is -device usb-wacom-tablet which more closely emulates an actual wacom tablet so maybe that could work better if the default usb-tablet is not recognised by AmigaOS's HID driver but I did not try these. That's worth a try. No time for it right now, though. Hans
|
|
|
|
|
|
Re: Touchscreen HID driver & QEMU's USB Tablet device
|
Posted on: 2/23 23:59
#32
|
Home away from home
|
@AlfredOne Quote: @hans, can you tell me if the 3 buttons are physically on the tablet or are they emulated by qemu? There is no actual tablet. I'm using a laptop with a trackpad. The advantage of using the emulated "usb-tablet" with a mouse/trackpad, is that the guest OS gets the actual mouse pointer location. The Virtio GPU device uses the host OS' actual mouse pointer/cursor, which can cause weird interaction problems because both the host and guest OS are trying to control the mouse pointer's position. In "usb-tablet" mode, the guest OS gets the actual mouse position directly, and the fight between the guest and host OS can stop. Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home
|
@smarkusg
Yes, I have an nvidia GPU. Actually, it's one of those dual GPU setups with an Intel HD Graphics 530 for low power usage, and an nvidia 960M for when more GPU power is needed.
My Ubuntu setup might be stuck with using the Intel GPU only. I tried switching it to using the nvida at all times, and ended up with a black QEMU window (plus warnings a QEMU context reset due to a hung GPU).
So, something's not working right on my system. The Intel GPU should still be more than fast enough, but who knows what else is wrong.
Regardless, it's good enough for me to finish working on the driver.
Hans
|
|
|
|
|
|
Touchscreen HID driver & QEMU's USB Tablet device
|
|
Home away from home
|
@all
I finally tried out QEMU's "tablet mode" for the mouse, and it doesn't work with the touchscreen driver. So, "-device usb-tablet" isn't an option, yet...
The USB log says that no driver was found for QEMU's tabled device:
I: [10:57:57] USB Fkt Init | Init Fkt | [fkt 0x6FF8FDC0] Fkt is {Vendor: 0x0627, Product: 0x0001, Class: 00.00}
I: [10:57:57] USB Fkt Init | Init Fkt | [fkt 0x6FF8FDC0] Fkt ("QEMU","QEMU USB Tablet","28754-pci.1:0c.3-1") initialized
I: [10:57:57] USB FD fkt start | Sys_EndInitialAttachmentPhase | Initial USB Attachment Phase terminated
I: [10:57:57] USB FD fkt start | BindInterfaceDriver | No interface driver of fkt 0x6FF8FDC0/ifc 0x5F95C190 {Class 03.00} has been found
W: [10:57:57] USB FD fkt start | Fkt FD launcher | [0x6FF8FDC0] Could not bind any suitable interface driver to fkt
@AlfredOne
Is the "QEMU USB Tablet" a USB touchscreen device? Or is a different protocol used?
EDIT: Should have started a new thread for this...
Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home
|
@balaton A bit of professional courtesy would be appreciated. You do NOT need to lecture a fellow developer about how posting problems on an obscure forum is unlikely to get them fixed. I haven't submitted any bug reports yet because, so far, I haven't had enough information to do so. Quote: But @Maijestro could also reproduce it on completely different hardware and OS so this may be something related to HIDPI display or QEMU. I just tried disabling scaling, and performance went up (still slower than expected, but a lot better). The mouse pointer also suddenly works just fine. Looks like HIDPI may indeed be a problem... Setting scaling to 200% also triggered a slow-down, and made the mouse pointer unusable again. So, any scaling is a problem. This looks like a system/driver issue (not sure which module is to blame, yet). I've seen plenty of complaints about fractional scaling causing performance issues (and other problems). AFAIK, Ubuntu is also on the conservative side when updating packages, so these problems may well have been fixed upstream already. The mouse pointer not handling scaling definitely is a QEMU issue, and there's already a bug report for it.** I'll add my observations to that ticket, and update the broken scaling bug report too... Hans ** NOTE: This is with the mouse pointer input being in normal mode. IIRC, the recommendation is to use tablet mode (with a suitable driver on the guest OS). I haven't tried that out yet.
Edited by Hans on 2024/2/23 5:27:52
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/22 14:13
#36
|
Home away from home
|
@all I'm pleased to say that updating to QEMU 8.2.1 fixed the GTK display. Unfortunately, the GTK display backend is now almost as slow as SDL2 when using the Virtio GPU device. Also, the Virtio mouse pointer is indeed completely unusable, as per this bug report. Looks like I have to put up with the slowness for now... Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/22 12:24
#37
|
Home away from home
|
@smarkusg
As I said earlier, the GTK backend is completely broken on my system when OpenGL is enabled, regardless of which emulated graphics card you use. It's the same when I use the emulated SM501. No idea why it works for you but not me (and some other people who reported the same issue).
Linux has a large number of distros with different setups. QEMU's GTK code itself has two OpenGL backends (one being EGL based).
The mouse pointer issue (in one of the bug reports I linked to) is specific to the Virtio GPU device. Emulated cards like the SM501 use a mouse pointer that's drawn directly to the window. Virtio uses the host system's actual mouse pointer.
The SDL2 slowdown with a Virtio GPU display may also be specific to my system. I've seen varying reports about Virtio GPU performance (with Linux guest OSes) from "near native" to "horribly slow." It seems to vary a lot depending on which distro, hardware, libs and drivers people have.
I can try upgrade to the latest release (8.2.1) and see if GTK works any better. I didn't see anything relevant in QEMU's commit history, though.
Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
Posted on: 2/22 10:32
#38
|
Home away from home
|
Adding SDL_GL_SetSwapInterval(0) did nothing, nor did my attempts to disable vsyncing in the drivers. My laptop has both an Intel and nVidia GPU, and I've got no idea which one it's using, or what the settings are (the nVidia control panel doesn't even have OpenGL settings).
Switching the desktop to 1920x1080 @60Hz did help, but flushing the image to screen is still hurting performance (reducing screen bitmap flushing to once every 6 frames gives approx. 3x speed up). It's still slower than the GTK backend.
I don't see anything wrong with QEMU's SLD2 GL code. Time for me to move on. I'll just have to live with it for now.
Hans
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home
|
@all The problem I encountered with the GTK display backend has been around for a few years already. There are other issues too, such as broken mouse positioning and refresh rate limiting. I suspect that my problem may be SDL2_GL_SwapWindow() waiting for a vsync, or the nVidia driver forcing a vsync. To make matters worse, my monitor runs at 30Hz in 4K.** If QEMU's Virtio GPU code is running in the same thread as the CPU emulation (and I suspect that it is), then emulation gets blocked by up to 33ms at a time. Hans ** Despite this, the VirtioGPU driver is told that it's got a 60Hz screen. So, it's trying to update the screen at that rate. I wish that the EDID that QEMU sends to Virtio GPU was based on the actual monitor's capabilities.
|
|
|
|
|
|
Re: Qemu GTK/SDL display problems
|
|
Home away from home
|
@smarkusg Quote: Linux - SLD works without any problem, there is no slowdown. Just don't know why you have "show-cursor=on" because then there are two indicators. I have it enabled, because Virtio uses the host OS' actual mouse pointer, and otherwise you can't see it. @vagappc Quote: SPICE (the Simple Protocol for Independent Computing Environments) is the best remote display for VM. Ah, okay. The SPICE software that I know, is the circuit emulator ( link). @all I think the SDL slowness is Virtio GPU specific. With SDL, flushing the screen bitmap to the monitor is incredibly slow. That's crazy, given that the screen bitmap is in an OpenGL texture, so blitting to the display window on the host OS should be incredibly fast. Either way, drawing graphics ends up being painfully slow unless reduce how often the display is flushed (which lowers the frame-rate). With GTK, the flush operation is way faster. @Maijestro Nice to see the problem confirmed, albeit with Cocoa instead of GTK. I was hoping someone would tell me that the GTK issue had been fixed, and I just needed to upgrade. I'm currently using v8.1.0 (self-compiled). @smarkusg Quote: I guess the problem on macOS and Cocoa was fixed already in the git version because I saw on the mailing list that you helped the developer to fix it. Thanks!!! Has it also been fixed for GTK? Or for Cocoa alone? Hans
|
|
|
|
|
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
