search

DacoTaco / priiloader

A Wii homebrew application that can prevent and fix some user level bricks
GNU General Public License v2.0
544 stars 101 forks source link

Wii Mini - plugged USB Keyboard causes crash. #249

Closed buggii closed 4 years ago

buggii commented 4 years ago

On Wii Mini:

If Priiloader is installed and you have a plugged USB Keyboard this causes a crash (black screen) when exiting to System Menu even from other homebrews. If you remove the keyboard (and have priiloader installed) the crash is gone and exiting to SYstem Menu works fine.

DacoTaco commented 4 years ago

what are your return to settings in priiloader? what kind of keyboard are you using? what usb port?

currently i can no reproduce the issue. what ive tried :

both worked fine, keyboard inserted in top usb port

buggii commented 4 years ago

Wii mini has just 1 usb port so I usually use a 4 ports usb3 hub with 1 flashdrive+keyboard . The problem is present even if i remove the hub (just using the keyboard),

Keyboard is a compact usb one (no numeric keypad).

I used the default option (I do not remember if it was return or exit to sysmenu) anyway it does the same if i have Priiloader installed, go to sysmenu (removing the keyboard), open HBC, exit from HBC (or other homebrews) them crashes if i have the Keyboard connected.

DacoTaco commented 4 years ago

you mention that other homebrew also crashes , im guessing you mean it crashes when in said homebrew you select to exit to system menu? does holding escape work to open up priiloader?

buggii commented 4 years ago

Priiloader works (opens up) holding the ESC button.

Yes, the crash is always on exit/going back to system menu from homebrews when Priiloader is installed and the usb Keyboard is connected.

DacoTaco commented 4 years ago

but it doesn't crash if you leave the keyboard inserted and start system menu from the priiloader menu?

buggii commented 4 years ago

It crashes if I leave the keyboard inserted and start system menu from the priiloader menu. If i hit the exit to menu and quickly remove just the Keyboard it doesn't crash so it seems to be something happening when sysmenu check something in the usb port and it find the usb keyboard (my idea).

DacoTaco commented 4 years ago

aha, if booting system menu from the priiloader menu also crashes it, we have a way to debug the issue.

just a test you could run right now : boot to the priiloader menu, connect a wiimote and then boot system menu (let it crash). is the wiimote connected or has it been disconnected?

buggii commented 4 years ago

I did exactly what you said:

started priiloader -> connected wiimote pressing a wiimote button (P1 blue led turns on) -> exit to system menu -> P1 blue led still on for 3 seconds the suddenly turns of by itself; from now on if I press a wiimote key all the 4 leds flashes for 10 times then they turn off (again and again at each button press).

DacoTaco commented 4 years ago

aha, so it probably shutdown the wiimotes and failing further down the line.

can you disable the autoboot settings (so it boots the priiloader menu) , enable the 'Dump Gecko output' setting and start system menu. let it crash, and then go and disable that setting again.

there should now be a prii.log file on the usb drive that hopefully doesn't end with 'Hacks:'.

thanks for testing and helping me locate the problem so far

buggii commented 4 years ago

You are welcome ! Here they are my tests:

--------gecko_output_enabled------ 8:9:50 : BootState:1 8:9:51 : Bootstate 1 detected. DiscState 2 ,ReturnTo 0 & Flags 132 & checksum 2214658560 8:9:52 : Input_Init():1 8:9:54 : FAT_Init():1 8:9:55 : priiloader v0.90 BETA 3 (Sys:4610)(IOS:80)(Feb 1 2020 20:52:31) --------gecko_output_enabled------ --------gecko_output_enabled------ 8:10:10 : using 00000008 for booting 8:10:12 : loading hacks 8:10:13 : _processLine Exception: Invalid patch : 0x3B0000F90x387 8:10:15 : line : patch=0x3B200001,0x3B0000F90x387

Notes: when I enable the geck dump function it tooks some seconds for it to be enabled; also booting into priiloader again (with that option enabled) is quite slow (some seconds) but this should be normal.

Offtopic: I also just noticed that the "stop disc at startup" hack is not present, can you add it please ?

buggii commented 4 years ago

Another test I did:

Same as above but WITHOUT disabling autobooting into system menu and WITHOUT any keyboard connected (just the USB HUB + USB drive) ant it still crashes:

--------gecko_output_enabled------ 8:20:22 : BootState:1 8:20:24 : Bootstate 1 detected. DiscState 2 ,ReturnTo 0 & Flags 132 & checksum 2214658560 8:20:25 : Input_Init():1 8:20:26 : AutoBoot:System Menu 8:20:28 : using 00000008 for booting 8:20:29 : loading hacks 8:20:30 : _processLine Exception: Invalid patch : 0x3B0000F90x387 8:20:32 : line : patch=0x3B200001,0x3B0000F90x387 8:20:33 : Hacks:61 8:20:34 : applying Block Disc Updates

If I do not connect anything into the USB port - no keyboard, no USB drive, no USB hub - (having 'Dump Gecko output' enabled) the crash is solved, the console does not crash.

If I just connect the USB hub WITHOUT USB keyboard and WITHOUT USB flash drive the crash is solved too, the console does not crash.

Summing it up connecting:

So the problem seems to be related also to USB flash drives if the "gecko" option is enabled, but if it is disabled the crash only happens with USB keyboards.

DacoTaco commented 4 years ago

probably unrelated, but i see its having issues reading the hacks file correctly too. do you mind updating with the following installer to make sure its not related to the issue : http://upload.dacotaco.com/boot_hacks_fix.dol

also, do you only have the one hack enabled (block disc updates) ? to me it looks like something is not liking the usb controller :/

EDIT : btw, is the keyboard the only way for you to enter the priiloader menu on your wii mini?

buggii commented 4 years ago

I re-installed with the new .dol but the crash happens again.

Yes, no other way to enter priiloader, only the keyboard.

I don't remember if I told you but also if you turn the Wii Mini off, then on with priiloader installed+usb keyboard connected I get the crash, without entering priiloader.

UPDATE: I just found a way to exit from the crash (so it is not a real crash): when I start the system with the keyboard attached and all seems crashed (blue screen) -> if I press A KEY ON THE KEYBOARD (no matter which one) the system menu appears after 2-3 seconds ! The same thing if I return to system menu from an homebrew !

It is like the system (priiloader?) is waiting for the press of a button (the ESC key ?) on the keyboard to start the menu; is there a timer like "if no key is pressed after xxx seconds" the system will boot ?

DacoTaco commented 4 years ago

UPDATE: I just found a way to exit from the crash (so it is not a real crash): when I start the system with the keyboard attached and all seems crashed (blue screen) -> if I press A KEY ON THE KEYBOARD (no matter which one) the system menu appears after 2-3 seconds ! The same thing if I return to system menu from an homebrew !

huh, thats interresting.

It is like the system (priiloader?) is waiting for the press of a button (the ESC key ?) on the keyboard to start the menu; is there a timer like "if no key is pressed after xxx seconds" the system will boot ?

no there is no such timer, but i suspect your keyboard is acting differently then both my keyboards. im like 80% sure its stuck trying to stop the keyboard thread.

could you install this for a second : https://upload.dacotaco.com/boot_extra_logging.dol it has extra logging for me to check now that we know more about the issue.

i suspect to see a line saying 'killing kb thread' and after a while (as you waited before pressing the key) 'killed'

DacoTaco commented 4 years ago

though still waiting for the results of the test & logs, ill tag @Fullmetal5 as it was his PR that added this change. @Fullmetal5 , why was the keyboard implementation chosen over the usbkeyboard ? i have a suspicion that the KEYBOARD_GetEvent is locking up until a button is pressed, disallowing the thread to exit, while usbkeyboard seems to work through IOS and devoptab_t

EDIT : or do you have any idea why his keyboard/wii mini would crash upon booting system menu?

buggii commented 4 years ago

Here it is the test, I waited at least 10 seconds before pressing a key on the keyboard (anyway after I press a key on the keyboard the black screen remains):

--------gecko_output_enabled------ --------gecko_output_enabled------ --------gecko_output_enabled------ 23:5:48 : using 00000008 for booting 23:5:50 : loading hacks 23:5:51 : _processLine Exception: Invalid patch : 0x3B0000F90x387 23:5:52 : line : patch=0x3B200001,0x3B0000F90x387 23:5:53 : killing kb thread... 23:5:54 : killed 23:5:59 : input shutdown 23:6:0 : Hacks:61 23:6:2 : applying Block Disc Updates 23:6:3 : Found Block Disc Updates @ 0x4FFBC, patching hash # 1... 23:6:4 : Found Block Disc Updates @ 0x50014, patching hash # 2... 23:6:5 : applying Block Online Updates 23:6:7 : Found Block Online Updates @ 0x3622F8, patching hash # 1... 23:6:8 : applying Auto-Press A at Health Screen 23:6:9 : Found Auto-Press A at Health Screen @ 0x8E134, patching hash # 1... 23:6:10 : applying Replace Health Screen with Backmenu 23:6:11 : Found Replace Health Screen with Backmenu @ 0x329294, patching hash # 1... 23:6:13 : applying Move Disc Channel 23:6:14 : Found Move Disc Channel @ 0x80808, patching hash # 1... 23:6:15 : applying Wiimmfi Patch v1 - hidden MASTER 23:6:16 : added offset to list 0x812FF030 23:6:18 : applying Wiimmfi Patch v1 for Wii Mini PAL 23:6:19 : added offset to list 0x8137C35C 23:6:20 : added offset to list 0x812FF000 23:6:21 : applying 480p graphics fix in system menu 23:6:22 : Found 480p graphics fix in system menu @ 0x210C18, patching hash # 1... 23:6:24 : added offset to list 0x812FEFE0 23:6:25 : applying Remove NoCopy Save File Protection - Master

buggii commented 4 years ago

The same test waiting 20 seconds from the "crash" to the keyboard button press:

23:14:0 : USB: Mounted 23:14:13 : using 00000008 for booting 23:14:14 : loading hacks 23:14:15 : _processLine Exception: Invalid patch : 0x3B0000F90x387 23:14:17 : line : patch=0x3B200001,0x3B0000F90x387 23:14:18 : killing kb thread... 23:14:19 : killed 23:14:35 : input shutdown 23:14:36 : Hacks:61 23:14:38 : applying Block Disc Updates 23:14:39 : Found Block Disc Updates @ 0x4FFBC, patching hash # 1... 23:14:40 : Found Block Disc Updates @ 0x50014, patching hash # 2... 23:14:41 : applying Block Online Updates 23:14:42 : Found Block Online Updates @ 0x3622F8, patching hash # 1... 23:14:44 : applying Auto-Press A at Health Screen 23:14:45 : Found Auto-Press A at Health Screen @ 0x8E134, patching hash # 1... 23:14:46 : applying Replace Health Screen with Backmenu 23:14:47 : Found Replace Health Screen with Backmenu @ 0x329294, patching hash # 1... 23:14:49 : applying Move Disc Channel 23:14:50 : Found Move Disc Channel @ 0x80808, patching hash # 1... 23:14:51 : applying Wiimmfi Patch v1 - hidden MASTER 23:14:52 : added offset to list 0x812FF030 23:14:53 : applying Wiimmfi Patch v1 for Wii Mini PAL 23:14:55 : added offset to list 0x8137C35C 23:14:56 : added offset to list 0x812FF000 23:14:57 : applying 480p graphics fix in system menu 23:14:58 : Found 480p graphics fix in system menu @ 0x210C18, patching hash # 1... 23:14:59 : added offset to list 0x812FEFE0 23:15:1 : applying Remove NoCopy Save File Protection - Master 23:15:2 : Found Remove NoCopy Save File Protection - Master @ 0x24678, patching hash # 1... 23:15:3 : Found Remove NoCopy Save File Protection - Master @ 0x96230, patching hash # 2... 23:15:4 : applying Remove NoCopy Save File Protection 23:15:5 : Found Remove NoCopy Save File Protection @ 0x1E97C, patching hash # 1... 23:15:7 : Found Remove NoCopy Save File Protection @ 0x293E28, patching hash # 2... 23:15:9 : applying Region Free Everything - Master 23:15:10 : Found Region Free Everything - Master @ 0x4E628, patching hash # 1...

DacoTaco commented 4 years ago

this is starting to make no sense. the input is shut down, the keyboard should not have any effect on the system anymore yet you say that pressing a button sets it back in motion normally (without logging enabled), yet the logging shows it goes waaaaaay past killing input and the keyboard.. sadly, the logging stops there as after that it loads the loader into memory, shuts down storage devices, USB & system related stuff and loads the binary. i suspect the same things happens when loading autoboot or loading a binary in the installed file menu?

--------gecko_output_enabled------ 8:9:50 : BootState:1 8:9:51 : Bootstate 1 detected. DiscState 2 ,ReturnTo 0 & Flags 132 & checksum 2214658560 8:9:52 : Input_Init():1 8:9:54 : FAT_Init():1 8:9:55 : priiloader v0.90 BETA 3 (Sys:4610)(IOS:80)(Feb 1 2020 20:52:31) --------gecko_output_enabled------ --------gecko_output_enabled------ 8:10:10 : using 00000008 for booting 8:10:12 : loading hacks 8:10:13 : _processLine Exception: Invalid patch : 0x3B0000F90x387 8:10:15 : line : patch=0x3B200001,0x3B0000F90x387

yet this logging shows me that it didn't get to kill input? is this logging complete?

EDIT : just noticed, you have 'Replace Health Screen with Backmenu' enabled, is this the fixed version?

Fullmetal5 commented 4 years ago

@DacoTaco Sorry, I've been busy (finals). I'll look into this some tomorrow and try to see what's causing problems. Also the reason I didn't go with the normal keyboard event handle built into libogc is because it was causing problems and sometimes just not working. Actually just looking back over the code I noticed I forgot to replace the argument to KEYBOARD_Init with NULL instead of HandleKBDEvent. You might try changing that to NULL like it should be because that is creating another thread.

buggii commented 4 years ago

Yes i copy/pasted all' the log Lines and Yes, the backmenu hack is the fixed Version.

DacoTaco commented 4 years ago

@Fullmetal5 : i saw it creates another thread, which is why i started looking into the usbkeyboard implementation which uses the keyboard implementation with the callback you give it when calling USBKeyboard_Scan. this was the implementation that was giving issues for you, or are you thinking of the regular keyboard (keyboard.h/.c) implementation? the usbkeyboard implementation seems to work fine here..

good luck with your finals man! we got time :)

@buggii Fullmetal has a point on the code change. try https://upload.dacotaco.com/boot_cb_fix.dol it should've been able to kill the internal thread, but if not, this will fix it.

buggii commented 4 years ago

Sorry to be late. Tested the new .dol but the problem persists: I still need to press a keyboard button to boot wii mini when prilloader is installed or going back to menu from an homebrew.

EDIT (off topic but: is it possible to block disc spinning at power up also for Wii Mini ?)

DacoTaco commented 4 years ago

Sorry to be late. Tested the new .dol but the problem persists: I still need to press a keyboard button to boot wii mini when prilloader is installed or going back to menu from an homebrew.

i just redid a bit of the keyboard code https://upload.dacotaco.com/boot_new_keyboard.zip could you try and boot the priiloader_new_keyboard in HBC and check if it works and the keyboard works? if it works, you can install it using the boot_new_keyboard.dol

on my wii and with my Keyboard it looked to be working fine :/

EDIT (off topic but: is it possible to block disc spinning at power up also for Wii Mini ?)

the setting doesn't work when entering the wii menu?

buggii commented 4 years ago

Test done, the problem persist identical. The problem appears also if I launch the priiloader_new_keyboard from HBC: I run it and I must press a keyboard button in order for it to be loaded (to see the priiloader menu on screen).

About the disc spinning hack in Wii Mini: that hack does not appear at all in the hacks list.

DacoTaco commented 4 years ago

and the last logging line is the same as before? it applying the hacks?

EDIT : about the disc thing, it isn't a hack and i couldn't find anything about it ever being a hack. the only stopping disc functionality i found in the past and current is the setting that stops disc when entering the priiloader menu. thats it. see the other issue on github about it. i should close that issue..

DacoTaco commented 4 years ago

ping, did you check the logging ?

buggii commented 4 years ago

Sorry to be late :P

I run it with gecko log enabled and the console crashes at start if I connect the keyboard and/or the USB flash drive, even if I press a key on the keyboard (hangs at blue "no-video" screen) so enabling log causes a "brick" that can be solved only removing any USB devices.

About the "disc thing" you are right, it is under "settings", my fault, sorry :P

Here it is the log with gecko-log enabled (I just turned the console on and waited at least 60 seconds, then I tried to press some keys on the keyboard with no results; after that i forced a shut down holding the power button):

--------gecko_output_enabled------ 14:33:42 : BootState:1 14:33:43 : Bootstate 1 detected. DiscState 2 ,ReturnTo 0 & Flags 132 & checksum 2214658560 14:33:45 : Input_Init():0 14:33:46 : AutoBoot:System Menu 14:33:47 : using 00000008 for booting 14:33:49 : loading hacks 14:33:50 : _processLine Exception: Invalid patch : 0x3B0000F90x387 14:33:51 : line : patch=0x3B200001,0x3B0000F90x387 14:34:16 : input shutdown 14:34:17 : Hacks:61 14:34:18 : applying Block Disc Updates 14:34:20 : Found Block Disc Updates @ 0x4FFBC, patching hash # 1... 14:34:21 : Found Block Disc Updates @ 0x50014, patching hash # 2... 14:34:22 : applying Block Online Updates 14:34:23 : Found Block Online Updates @ 0x3622F8, patching hash # 1... 14:34:24 : applying Auto-Press A at Health Screen 14:34:26 : Found Auto-Press A at Health Screen @ 0x8E134, patching hash # 1... 14:34:27 : applying Replace Health Screen with Backmenu 14:34:28 : Found Replace Health Screen with Backmenu @ 0x329294, patching hash # 1... 14:34:29 : applying Move Disc Channel 14:34:31 : Found Move Disc Channel @ 0x80808, patching hash # 1...

DacoTaco commented 4 years ago

hmm, that log also shows it being able to shutdown the keyboard thread...

to figure out where it goes wrong i tried to make a testing dol that needs to be started from HBC http://upload.dacotaco.com/usbTest.dol

run this, press home to exit and check if it also hangs. if so, what is the last line it shows before you have to press a button on the keyboard?

thanks a lot to help me figure this issue out btw :)

buggii commented 4 years ago

I just tested without usb keyboard and it exits fine after the second "home button press".

If I connect the USB keyboard it hangs at

"killing kb thread..."

untill I press a keyboard button (I can try to press any wiimote button without success); after that keyboard button press (I pressed ENTER key) It writes:

begin event handle event 0 keyCode 0x28 pressed! killed begin event handle event 2 shutting down usb done press start/home afain to exit exitting

So after that keyboard button press everything seems to work fine.

It seems it needs a keypress to kill kb thread... I hope this can be solved/circumvented.

DacoTaco commented 4 years ago

what? in this test app the thread fails to exit, yet in the priiloader log above it had passed it long before that (as seen by the hacks being applied) ? this is weird, but i guess we can test further with this test app (if i ever find the issue...)

if i see that output, i suspect the thread is hanging somewhere , so i uploaded a new version (same url, see above) and try it. it removes the USB_Scan which scans the keyboard for events and triggers the event handler (which is the begin event handle thing you see). 0 is keypress and 2 is disconnect (because of the keyboard deinit). verify the dol is from today thou , just to be sure youre not using the same one again :)

Fullmetal5 commented 4 years ago

After looking at the code more it doesn't seem to make sense how there could be a hang in the kbd_thread. The function is very small and the only external function it calls is to KEYBOARD_GetEvent which only calls in __lwp_queue_get which never blocks so it doesn't make sense. @DacoTaco Can you put some printfs (either to sd/usb or on screen if necessary) around both sides of the calls to LWP_JoinThread for the keyboard thread and KEYBOARD_Deinit for buggii to test to see if either of them is the one hanging. It shouldn't hang in LWP_JoinThread but KEYBOARD_Deinit is slightly more complicated and might be the culprit here.

Fullmetal5 commented 4 years ago

Huh, just read more of the responses, sorry. It seems like it really isn't hanging in the keyboard thread at all. This looks like some issue with either libogc or IOS getting stuck waiting for a call. Daco, in BootMainSysMenu there is a call to ShutdownDevices and USB_Deinitialize, since the issue is definitely usb related try adding some printfs around them and then just have it hang instead of calling loader so that the screen stays. It might be getting stuck in the call to USB_Deinitialize as it issues some synchronous ioctls and they might get stuck if IOS is waiting for an event.

DacoTaco commented 4 years ago

see last comment. in priiloader i see it closing the keyboard and what i also suspected was usb_deinit giving issues. however, in the test app i am now testing it in it shows to get stuck in the thread closing so im not sure where it is anymore.

it is indeed probably an issue in libogc, which is why im trying to find the issue. if we find the issue and solve it im going to try and upstream it.

buggii commented 4 years ago

Test done. After pressing the home button for the 1st time i get:

kthxbye killing kb thread... killed begin event handle event 2 shutting down usb done press start/gome again to exit

and when I press the home button again it exits correctly.

DacoTaco commented 4 years ago

ha, so it is the keyboard scan blocking :/ i added some printfs in every scan to see what happens. can you check? https://upload.dacotaco.com/usbTest_debug.dol

i suspect it will hang on a ''USB_ReadIntrMsg" and show "done" when you press a key?

buggii commented 4 years ago

When I start the app it hangs on "'USB_ReadIntrMsg" and if I press a keyboard button (just 1 button press, not 2 button press) it says:

done begin event handle event 0 keyCode 0x28 pressed! USB_ReadIntrMsg done begin event handle event 1 keycode 0x28 released! USB_ReadIntrMsg

and it hangs again waiting for another keyboard button press.

If I open the app and press the wiimote home button (without pressing any key) it says:

kthxbye killing kb thread...

If I open the app, press a keyboard button and then press the home button I get the sum of the above 2 logs:

done begin event handle event 0 keyCode 0x28 pressed! USB_ReadIntrMsg done begin event handle event 1 keycode 0x28 released! USB_ReadIntrMsg (here I press a button) kthxbye killing kb thread...

So it seems that that the program can go further (works if I press the home button) even if the USB process is hanging.

DacoTaco commented 4 years ago

haha, so its as i expected. what keyboard are you using? do you have another to try?

i'd need to look if there is a possibility to add a timeout or do it async in libogc cause it seems the keyboard isn't sending a report in a timely fashion like the hid specs say they should (afaik)

buggii commented 4 years ago

The full keyboard name when I bought it was:

KEYBOARD ULTRA SLIM USB 2.0 PS3 PS4 PC NOTEBOOK LINQ KM-681

so it is a LINQ KM-681.

Unfortunately I do not have any other USB keyboard to test with (I bought that one just for Wii Mini :P ).

DacoTaco commented 4 years ago

hey,

ive been looking at the usbkeyboard code and tried a few things locally. the most stable solution was sending a USB_Halt when shutting down the keyboard. this should cause the keyboard thread to continue (by dropping its request) and fix the thread not exiting with your keyboard.

i can't test this myself fully , but it should work in theory! also, please note that there is a visual bug in there in that it might only show 'done' at the end instead of the 'press home again to exit', just press home then.

http://upload.dacotaco.com/usbTest_Halt.dol

buggii commented 4 years ago

Test done:

it says:

loaded ios 58! kb thread started press start on GC controller (or home on wiimote) to exit starting scan read usb (here the program seems to be hanged)

then i press a keyboard button and it says:

done- begin event handle event 0 keyCode 0x28 pressed! reset busy starting scan read usb done- begin event handle event 1 keyCode 0x28 released! reset busy starting scan read usb (then here it seems to hangs again and again at each keyboard button press)

if, instead, I open the program and I press the HOME button (I do not press any keyboard button):

loaded ios 58! kb thread started press start on GC controller (or home on wiimote) to exit starting scan read usb (here the program seems to be hanged)

then i press THE HOME BUTTON and it says:

kthxbye closing... sending halt (here it hangs again and i MUST press a keyboard button to go on):

When I press a keyboard button it continues with:

done- begin event handle event 0 keyCode 0x28 pressed! reset busy closing begin event handle event 2 killing kb thread... killed shutting down usb done press start/home again to exit

and if i press home it exits correctly.

DacoTaco commented 4 years ago

ok, so that didn't work. i will continue to research this :) thanks so far :)

DacoTaco commented 4 years ago

hey, i got 2 more tests lol. this was some stuff i was playing around with this weekend before i wanted to try the halt stuff. i got it to be more stable on my end, so its worth a try i guess.

first test closes usb and assumes a message will come back from it saying closed. but im not sure it works that way. my keyboard responds in timely fashion so i dont know if its that, or sending a msg because its getting closed. i suspect this one will hang/crash but its worth a shot : https://upload.dacotaco.com/usbTest_wait_call.dol

then there is another test which polls the keyboard async that can be cancelled/stopped when a close is called. this i have somewhat hope for : https://upload.dacotaco.com/usbTest_semaphore.dol

thanks!

( btw, these tests are all changes in libogc code and have gone way past priiloader code lol )

buggii commented 4 years ago

TESTs done::

TEST 1 - wait_call dol:

loaded ios 58! kb thread started

press start on GC controller (or home on wiimote) to exit USB_ReadIntMsgAsync (here it hangs)

then I press the HOME button and it says: kthxbye closing begin event handle event 2 waiting for call to finish (here it hangs and I MUST press a keyboard button to go on)

oh, callback! shutdown detected bye thread kill semaphore killing kb thread... killed shutting down usb done press start/home again to exit (then i press HOME button and it exits correctly)

TEST 2 - with semaphore dol:

loaded ios 58! kb thread started

press start on GC controller (or home on wiimote) to exit USB_ReadIntMsgAsync (here it hangs)

then I press the HOME button and it says:

kthxbye closing begin event handle event 2 waiting for call to finish shutdown detected bye thread killing kb thread... killed shutting down usb done press start/home again to exit (then i press HOME button and it exits correctly)

So the last test SEEMS TO WORK FINE !

DacoTaco commented 4 years ago

alright, so the semaphore and async call works as expected! PROGRESS! :D however, besides cleanup of my testing code, there is stuff i still need to think about and discuss with the libogc team before i make it permanent. the call it broke out of can still run code after its closed and thats not ok :/

EDIT : could you try something @buggii , run the last dol again, but before you press home for the last time press a button on the keyboard. does it say 'oh, callback' ?

buggii commented 4 years ago

Test done.

Yes, it says "oh, callback"; if I press another keyboard button it does nothing; when i press the home button again it exits correctly.

DacoTaco commented 4 years ago

crap. ye, thats not good... that means IOS still triggers the callback despite the device being closed. that could cause crashes like the old HBC/AHBProt bug. i'll look into it, but currently can't think of a solution <<

DacoTaco commented 4 years ago

Ok, little update : i got the same keyboard here with me and did some testing and investigation.

tl;dr version : there was a bug in libogc that made the USB_Halt test we did before not work properly when running under newer IOS versions (it would've worked under IOS36). the patch will be sent upstream to libogc. this means priiloader 0.9 Beta 4 will have to be released once a new libogc version is released with this change

technical info : as we have seen before, this keyboard does not send interrupts to the usb host in timely fashion like other devices do. this makes the keyboard scanning thread block and therefore lock the application.

i added a Halt to the usbkeyboard code (like before) that when closing the keyboard it also stops all ongoing requests. however, this was broken with hidv5 aka on higher IOS versions

both fixes have been made and are going to be sent to libogc for approval

buggii commented 4 years ago

Thank You very much for your help!

DacoTaco commented 4 years ago

i see wintermute merged the fix into libogc, so now its waiting unill the new libogc is released :)

for now, could you test the following dol in HBC? it's priiloader with the keyboard fix (not the installer, actual priiloader) http://upload.dacotaco.com/boot_kb_fix.dol

buggii commented 4 years ago

Just tested:

Keyboard seems to work fine.

I launch it from HBC and it DOES NOT need to press any keyboard button to start !

Retrun to HBC works well (i see a greenish glitch at the bottom of the screen while black screen before HBC appears but it was there also in previous versions).

Returning to System Menu just seems to restart priiloader (so it DOES NOT reboot to System Menu correctly).