Homebrew Homebrew Development

  • Thread starter Thread starter aliak11
  • Start date Start date
  • Views Views 1,475,017
  • Replies Replies 6,048
  • Likes Likes 54
It's not disabled ... in other homebrew it's working fine. And it works sometimes in my homebrew - but very rarely - and I have no clue what could be the cause for making it work or not work. Is there a way to query the button explicitly and let the application suspend itself when the button is pressed?
 
It's not disabled ... in other homebrew it's working fine. And it works sometimes in my homebrew - but very rarely - and I have no clue what could be the cause for making it work or not work. Is there a way to query the button explicitly and let the application suspend itself when the button is pressed?
If it works sometimes, chances are it has a dirty contact point or something. It could also just be a damaged tact switch.

You are able to repair it, but if you want a way to get to the home menu, you can always press the power button, close your system and open it back up. That will bring you to the home menu. It will also close the application.

If the button is dirty, if you are comfortable with it. Taking apart your DS and then using some isopropyl alcohol on it will most likely clean it up. But that's only if it's dirty.

I'd honestly use the power button method.
 
It's not disabled ... in other homebrew it's working fine. And it works sometimes in my homebrew - but very rarely - and I have no clue what could be the cause for making it work or not work. Is there a way to query the button explicitly and let the application suspend itself when the button is pressed?
do you call aptMainLoop() reguarly?
 
Yes, calling aptMainLoop regularly. Here is some sample code to reproduce the issue
Code:
#include <stdio.h>
#include <3ds.h>

int main(int argc, char* argv[])
{
    gfxInitDefault();
    consoleInit(GFX_TOP, NULL);
    printf("\n\nPress START to quit\nHOME-button does not work\n");

    // Main loop
    while (aptMainLoop())
    {
        hidScanInput();
        u32 kDown = hidKeysDown();
        if (kDown & KEY_START)
            break;
    }
    gfxExit();
    return 0;
}
 
If it works sometimes, chances are it has a dirty contact point or something. It could also just be a damaged tact switch.

You are able to repair it, but if you want a way to get to the home menu, you can always press the power button, close your system and open it back up. That will bring you to the home menu. It will also close the application.

If the button is dirty, if you are comfortable with it. Taking apart your DS and then using some isopropyl alcohol on it will most likely clean it up. But that's only if it's dirty.

I'd honestly use the power button method.
Hardware is not an issue - it's a software thing. The home button works good in other apps.
 
My homebrew ... the app that I am developing.
This is the Homebrew Development thread, right?
I could be wrong but I thought the Home button was spotty for homebrew applications and that is why all the examples use the Start button to exit or have a menu item to specifically exit the application.
 
I could be wrong but I thought the Home button was spotty for homebrew applications and that is why all the examples use the Start button to exit or have a menu item to specifically exit the application.
Those times are long past :-) In all homebrew that I know, the HOME-button works. Apart from this, another symptom of the home button not working is, that the app will not sleep when shutting the 3ds lid or - even worse - not wake up when opening the lid. The small example program above is showing the issue: It will not sleep when closing the lid.
 
Add these lines: https://github.com/devkitPro/3ds-ex...cs/printing/hello-world/source/main.c#L36-L41

APT and/or hid stuff probably doesn't like being called in a tight loop without some delays.
Now, this is where it gets interresting: In my homebrew, I actually call gspWaitForVBlank() regularly (not the gfx.. functions because I use citro3D) - but in another thread where all my graphics handling is located.
My main thread contains the app functionality and generates the screen output, the second thread regularly paints the output of the main thread to the screen.
It somehow looks to me that the main thread needs to call gspWaitForVBlank() (or more specifically svcSendSyncRequest(gspGpuHandle)) regularly for the HOME button to work. If I insert the said call into my main thread, the home button is working - but only until the call clashes with the other GSP calls in the second thread which crashes the 3DS with "prefetch abort (kernel panic)" in gsp process. That's why I'm wondering if there is any other way to enable the home button which does not involve any gsp calls ...
 
Usually you want to do gsp stuff on the same thread that requested rights from gsp (or more generally speaking the thread that called gfxInit() or the default variant of it). If gspWaitForVBlank() fails it will return early and cause too many calls to apt/hid code.
 
Usually you want to do gsp stuff on the same thread that requested rights from gsp (or more generally speaking the thread that called gfxInit() or the default variant of it). If gspWaitForVBlank() fails it will return early and cause too many calls to apt/hid code.
Thanks for the hint. I modified the above example program and shifted all gsp calls to the second thread. However, the home button is still not working. Please check the modified version below:
Code:
#include <stdio.h>
#include <3ds.h>

volatile bool runThread = true;
volatile bool gfx_isinit = false;

void threadMain(void *arg) {
    gfxInitDefault();
    consoleInit(GFX_TOP, NULL);
    gfx_isinit = true;

    while(runThread) {
        gfxFlushBuffers();
        gfxSwapBuffers();
        gspWaitForVBlank();
    }
    gfxExit();
}

int main(int argc, char* argv[])
{
    Thread threadHandle = threadCreate(threadMain, 0, 4 * 1024, 0x19, -2, false);
    while (!gfx_isinit) svcSleepThread(10000000);

    printf("\n\nPress START to quit\nHOME-button does not work\n");
    // Main loop
    while (aptMainLoop())
    {
        hidScanInput();
        u32 kDown = hidKeysDown();
        if (kDown & KEY_START)
            break; // break in order to return to hbmenu
    }
    runThread = false;
    threadJoin(threadHandle, U64_MAX);
    threadFree(threadHandle);
    return 0;
}
 
Because the main thread is still in a tight loop calling aptMainLoop() and hidScanInput(). It's annoying i know but that's hoe it works best. Calling these 2 functions once every frame.
 
Yeah, that's the answer I feared - that would mean a shitload of work for me. Is there absolutely no other way - like polling the home button manually or anything like that?
Why would it be a lot of work? The 3ds has cooperative threads btw, you must manually yeld so other threads can run. If you use svcsleepthread on both, that should make the home button work.
 

Site & Scene News

Popular threads in this forum