on some game exploit I have, calls to sceGeListSync / sceGeDrawSync never end because somehow on nearly all homebrews I try, nothing gets drawn to the screen so they infinitely wait for some not working screen drawing
I tried hooking them with sceKernelDelayThread(1000); instead to try, and then the homebrews will work correctly with sound and everything but the screen just won't display anything, that's why it really looks like they're never ending because nothing gets displayed.

really weird bug imho xD I'll add more info if i can get any other
for now this game is only able to display successfully Squarez and PSPFiler xD Other ones have the display bug

Edit : So it looks like actually, it's that the sceGe calls just won't draw anything to VRAM memory like they should (both cached / uncached VRAM memory aren't modified)
If somehow I can find a way to force sceGe to draw or simply draw what it should in VRAM then this display bug would be solved
So to be clear, only homebrews drawing directly into VRAM by themselves are able to display correctly for now, hence why only PSPFiler / Squarez / text menu

SOLVED :
Found a way to fix the issue ! Used an sceGeListUpdateStallAddr(qid, NULL); on the latest qid the game had, by reversing a little to find the game's store address for qids and somehow it fixes it no idea why .. xD
And now everything gets drawn correctly !

Edit:
I made a big mistake, after further research it appears sceGeListUpdateStallAddr(qid, NULL) has been fixing my issue and not sceGeListDeQueue(qid); (which can't be called by hbl at all anyway even with user module stubs). My game imports sceGeListUpdateStallAddr which is imho the sole way to be able to use this syscall from pure 6.6x user mode.
Thing is my sceGeListDeQueue wasn't imported so had nops, and so the next syscall (sceGeListUpdateStallAddr) in my scrathpad hbl table got called and luckily it happened to be the fix xD