Okay, I figured it out. I have also HunoPPC's libegl wrapper installed.

It has its only set of configuration files in ENV/ENVARC:EGL_wrap directory. But SDL3 scans all sub directories it also picks up ENV:EGL_wrapper/SDL_RENDER_DRIVER and overwrites ENV:SDL_RENDER_DRIVER.

My suggestion is to call ScanVars with the flag GVF_SCAN_LEVEL (do not recurse into sub dirs).

@Capehill

Thanks a lot. Looking the Snoppy log it seems that ScanVars fails on my system.

Not sure why, but that would explain why using the SDL3 Prefs does not do anything.

Somehow I cannot get the Debug output to work, even when rebuilding SDL3 with debug.

I see if I can use printf to get the exact error.

@Capehill

Thanks a lot for checking. It is really strange that there are no GetVar calls in SDL3's testsprite.

I checked SDL2's testsprite2, and it works correctly; it defaults to compositing and the renderer can be set by setenv SDL_RENDER_DRIVER.

Strange thing is that I also do not see any GetVar calls in testsprite2, too. But it seems to work.

Is there another way to get the variable besides GetVar?

BTW, this what testsprite logs regarding the renderer:


I am not sure where the opengl is coming from...

@smarkusg @Capehill

It works when I set the renderer with the option "--renderer".

Not sure why the renderer defaults to opengl on my system. Any idea how SDL3 gets the renderer from? It clearly ignores SDL_RENDER_DRIVER.

@Capehill:

Not that I am aware of. I tried to set a different driver with SDL3 prefs, but the test program failed with the same error regardless of the selected driver (compositing, opengles2, software).

Thank you for the new version.

Not sure if this is my system or a new problem with SDL3. But the testsprite program does no longer run on my X5000:



The Minigl test programs in SDK:Examples/MiniGL do work, so I think there is no problem with my system.

@Hypex

Debugging never worked on the X5000... there was a bug in the X5000's kernel since day one.

Update 3 claimed that the X5000's kernel was finally fixed.

The update on my X5000 with Enhancer 2.2 did installed fine. Although I needed 6-7 attempts for the download on Saturday.

USB-Stack works much better - my A500 keyboard with a Keyrah 3 now attaches properly and HiDPI mice no longer only go up and down. Console seems to be a bit more stable and debugging looks better.

But I noticed following bugs:
- fast clicking and dragging in a console windows freezes the OS (no GR, no serial log)
- HiDPI mice loose their mouse rad scrolling sometimes. Might be causes by detaching/attaching via my KVM
- gdb crashes with DSI after running a program, step does run the complete program

Hi Thomas,

Yes, I connect the Keyrah 3 via a KVM switch. But I also tried to plug Keyrah into one of the USB slots on the backside of the X5000. No difference.

And the port is fine because the other machines (Raspberry Pi 5, two Windows laptops) do not have any issues when attach/detaching Keyrah. Or switching between the hosts with the KVM switch.

But I can create another set of logs using one of the backside USB ports (and detach all other USB devices but the mouse) if this would help you.

Hi Thomas,

thanks a log for your help on this.

I don’t have usbinfo available — neither on Workbench nor in the SDK.

I’ve prepared the requested files as follows:

- usb_versions.txt – contains the version numbers of all the USB modules you listed.
- usb_success.log – logs from a successful attach of the keyboard. For this to work, I had to completely shut down the X5000 and disconnect the keyboard for more than 5 seconds before powering back on.
- usb_failed.log – logs from a failed attempt after a cold reboot.
- usb_detach_and_attach.log – after the successful attach (as in usb_success.log), I unplugged and re‑plugged the Keyrah. The attach failed again in this case.

Please check if you can access the archive from OneDrive:
usb_logs.lha

Best regards,
Josef

Hi,

I am trying to use a Samsung A500 keyboard with my X5000. But it seems that Amiga OS 4.1 USB stack has some issues with the Keyrah.

Amiga OS 4.1 will not detect the Keyrah when plugged in after booting. Restarting the machine will also not detected it. The only way to make it work is to shutdown the X5000, wait a bit, and then start the OS while the Keyrah is attached. Even then it only works 1 in 3 tries. Either the Keyrah is not detected at all, or even if it is detected the OS does not register any key presses.

I do not see any messages on the serial debug when plugging in Keyrah.

When the Keyrah is detected and working, I see the following USB device in SysMon:



Keyrah works fine with the other machines (A600GS, two Windows laptops and a Raspberry Pi5).

Any ideas how to make the Keyrah V3 more reliable on AOS 4.1?

Thanks a lot,
Josef

System:
AmigaOne X5000/20
AmigaOS 4.1 FE Update 2
Enhancer 2.2

@amigakit

Thank you for releasing the fix. And sorry, I had to poke you because promised the fix already in 2022.

@smf

Thanks a lot. Yes, this seems to be the same issue. But the SDL3 installer is no longer using a trailing '/' for creating the directories so I could not reproduce the issue by installing SDL3.

Let's see if we ever see an update by amigakit.

@samo79:

I have MakeDir 54.11 (28.07.2022) from Enhancer, and SYS:Documentation/SDL3 is created just fine for when installing SDL3.

What version of MakeDir do you have?

@nbache

Thanks for the suggestion! I actually tried using FOREACH, but I couldn't get it to work recursively across subdirectories based on a pattern. To make it viable, I’d need to first feed it the output from a LIST command anyway. So at that point, I don’t see a clear advantage over just sticking with LIST and EXECUTE directly.

Detailed steps to resize PNG icons on AmigaOS 4.1:

1. Save this script as s:resize.py


2. Install PIL (https://os4depot.net/share/development/library/misc/pil.lha)
2a. Extract to RAM
2b. Execute RAM:PIL/Install_PIL

3. Create a script that calls s:resize.py on each #?.info file. Execute in Shell in the directory containing the info files:

3.a (Optional) Check the t:resize_all script in an editor

4. Execute created script in the same Shell:


EDIT: Please note the *" around %P%N. It is needed because the Path/filenames might contain spaces.

@DigitalDesigns

I am working on a version that works on Amiga OS 4.1. The initial script uses a few features that are not available on Python 2.5. The script is ready, but you need to install PIL from os4depot to make the script work.

Additionally, I need to figure out an easy way to call the script on each file. I keep you updated and I will provide steps how to do the conversion on AmigaOS.

@DigitalDesigns

The script is something I created with the help of CoPilot in a few minutes. It scans a given file, extracts all the embedded PNGs, resizes them to a specified dimension (default: 64×64), and writes them back as a single binary blob.

It was built with Python 3 and runs on Linux. You can pass in a custom size via the --size argument, and note: it overwrites the input file, so make a backup if needed.

I don’t take credit for the idea — feel free to tweak and use it however you like:


Usage Example — Convert all .info files in the current directory:



Let me know if you find it useful, or have ideas for enhancements!

@DigitalDesigns

First off, I recently purchased your Icon Pack and… wow. It's absolutely spectacular! Beautiful work!

Based on Maijestro’s feedback, I think he might be referring to a few things:

- Missing Emulation drawer in the Workbench setup
- Lack of icons for APPDIR, PIPE, and URL DOSDrivers

You've created a fantastic variety of custom Utilities drawers, but there are no icons for commonly used apps like:
- AmiPDF
- AmiUpdate
- AmiGS
- and more...

Some minor suggestions:

It’d be great to have a DataTypes folder with matching icons, similar to your DOSTypes drawer

And a few wishlist items for future updates (if you’re taking requests 😉):
- Filer drawer + app icon
- RunInUAE drawer + app icon
- Emulation Floppy drawer
- Emulation CinemawareGames drawer
- IMP3 drawer + app icon

Thanks again for such a visually rich and thoughtful pack — these icons would really look great on my Workbench!

BTW: I have a small Python script that splits your PNG icons, resize the individual images to 64x64 (configurable) and concatenates them again. The 256x256 are really detailed, but loading a lot of them (e.g. when opening Prefs drawer) takes a lot more time.

@nbache

Thank you very much for the update.

I found the first mentioning of this bug from 2011. So it is best not to hold my breath until it is finally fixed.