Homebrew [swkbd] Software keyboard research thread

[Sono]

As you may (or may not) know, we can't yet access the original Nintendo keyboard from homebrew. After many hours of researching, I found out, that launching the keyboard is very overcomplicated, and builtin ctrulib functions aren't enough to get the keyboard working (but it's possible to use ctrulib, if you add the line "extern Handle aptuHandle;" to the file include/3ds/services/apt.h).
So, let me share what I have researched so far:

• config structure
  • The structure size must be 0x400 (if not, then a "failsafe" keyboard is opened, see below)
  • If the structure is "invalid", the system freezes (probably a nullptr)
  • You'll need to use a special "SetInputData" function to properly initialize some variables, otherwise the structure is treated as invalid (which can be reprogrammed in homebrew, because it's just pure struct-access)
  • The text uses wchar_t, but in devkitPro it's 4bytes big (according to this), so we need to use u16 + the unicode lib in ctrulib instead of wchar_t
  • The keyboard requires a shared memory, or a kernel object we don't have access to (but it may be possible to reprogram it), or else the system will freeze (also, calculating the required shared memory is tedious, but can be done)
• launching
  • The keyboard is launched in a very specific way, and this makes it very hard to operate, because we need to re-implement most of the C++ stuff in plain ol' C in a homebrew environment
• misc
  • We can't have a spellchecker callback function, because we don't know where the original keyboard C++ object is stored. Also, it requires access to a function that sets 2 C++ variables, but because we don't know its address, we can't call it, so that's a double nope
• the "failsafe" keyboard
  • If we are lucky, and the system doesn't crash, we get a failsafe keyboard, which is just a plain parental control PIN input
  • Triggering the failsafe keyboard the second time either breaks the keyboard until next reboot (which could be probably fixed by forcing an applet unload), or softlocks the system, in both cases forcing a reboot.

 

[SANNIC789]

wow this is interesting thank you im hopeing this well 1 day work in something like dosbox or something

 

[cearp]

we still can't do it? annoying...
i think someone made a homebrew keyboard, right? is that the only solution, apart from every dev making their own?

 

[Sono]

we still can't do it? annoying...
i think someone made a homebrew keyboard, right? is that the only solution, apart from every dev making their own?

I just don't have time to continue research
Btw, with much work it's possible to use the keyboard, but it requires a very precise setup, and some functions access C++ variables somewhere I can't access it :/

 

[cearp]

I just don't have time to continue research
Btw, with much work it's possible to use the keyboard, but it requires a very precise setup, and some functions access C++ variables somewhere I can't access it :/

yeah don't worry, i guess this is good this seems nice in the mean time
http://gbatemp.net/threads/hbkblib-a-3ds-keyboard-library.397568/

 

[Red9419]

Isn't it possible to launch the keyboard using a leaked sdk? Distributing homebrew with that would be illegal so i guess it would be pointless.

 

[Sono]

yeah don't worry, i guess this is good this seems nice in the mean time
http://gbatemp.net/threads/hbkblib-a-3ds-keyboard-library.397568/

Ye, I know that But the original keyboard uses wide characters, so it should be possible to enter japanese characters.

--------------------- MERGED ---------------------------

Isn't it possible to launch the keyboard using a leaked sdk? Distributing homebrew with that would be illegal so i guess it would be pointless.

Let's say, it's not compatible with ctrulib, and requires a painful setup to compile. Also, appearently using those statically linked libraries is illegal...