Notices

Sweet!!!!

Thanks Nick!

So what do you think we can make out of this result?

It seems like to me that shutting down the hildon keyboard and immediately starting it up again fixes the output of Xkbd but now the tablet acts as if we were Spaniards. (???)

I think maybe this is why the ' " and ~ keys act funny after sending the gconftool command. It defaults to perhaps some other language when doing this.

All that's left is to send a signal to the tablet saying, "Hey! We're Americans! (or worst possible case of shame, Canadians)"

How could this possibly be done?

Changing the language on the hildon keyboard does nothing.

Anyone with an idea or a command line to try?


Qwerty!!!!

Qole!!!!

Why aren't you smart monkeys helping out here?


Oh, and before I forget to ask, is there any touch screen keyboard app that works perfectly in Diablo? I tried getting Xvkbd from this site but all the links were busted.

Addison I believe that xkbd stopped working ok after the OS upgrade because of some locale-related packages that were upgraded (or dropped in favour of some other) and were necessary to "sync" between the tablet locale and the xkbd one.
If I remember well the OS which you tested was the last one prior to N810 launch, and given that the N810 has a built-in keyboard that automatically disables the on-screen one when opened, it is possible that some "software switch" conflicts with Xkbd, too.

Thanks for still sticking around Nick.

I replaced the following Diablo files from the first OS release.
/usr/bin/locale
/usr/share/X11/locale/en_US.UTF-8/
/usr/share/locale/en_US/

I don't believe that did anything. Sure it worked here and there, but if I reboot I can get Xkbd fully working once or twice before it breaks without running any commands first.

I did find that replacing just this one file only along with the gconftool command, I can get all keys to work correctly.
/usr/share/X11/xkb/rules/base

I've tested this quite a lot and it seems to do the trick.

Only problem is the DPad no longer functions yet all of the other hardware keys do.

Now if I can get the DPad active again, this should be a reasonable solution.

I tried the trick you posted before but I'm not get the same results with the DPad, it's still dead on my end.

Here's the base file.
Base.zip

Any clue on what to try next and will you test that base file by overwriting your current one?

I'll gladly do it tomorrow (here in Italy is almost midnight ), I just hope keeping a backup copy of the "original" diablo base file will be sufficient to revert back to a working dpad
Did you already compare the content of the two files? Maybe there's some sort of subsection needed to define the Dpad behaviour that is missing on the older one you attached to your post

I can't read code Nick but there is a difference in size between the original and old file.

The thing is, even without replacing that base file I still had issues with the Dpad after running the gconftool command.

Sometimes it would come back but it would no longer repeat the movement in all 4 directions.

So like up and right might repeat but for left and down I needed to keep tapping the button.

Well, I look forward to hearing from you again tomorrow on this.

Commendable persistence, Addison!

xkbd or xvkbd or some equivalent *are* *needed* for some emulators (even on n810 and N900, due to special keys).

The layouts you created are very useful to show what is possible here. Lets keep this discussion active, at the very least.

Worst case is to still use Xkbd from before but replace the Caps Lock key with a Shift key instead.

It works pretty well, at least better than the Caps Lock key since that would constantly toggle the character output and was very frustrating to use.

I've now got a perfectly working Xvkbd 3.0 thanks to ukki and I'm currently looking at hacking it up.

It's so much more stable than Xkbd, but to edit it's layout, could takes months for me to understand.

Anyone willing to team up with me on this?

Addison, sorry for being so late, but i really screwed up my tablet (lost the Dpad and any mean of input swapping the files you suggested )
Maybe it was a human error (mine), maybe not, still I think changing random system files is not a good solution
I reflashed yesterday, now I have to restore my previous backed up state, and then I'll try again one more, so wish me luck

Heya Nick!

Don't bother messing with that base file, you're probably right about not using OS files from previous versions of Chinook.

Well, I've got another idea.

Could you install Xmodmap?

Try running in Xterm once before and then again after the gconftool command:
xmodmap -pk

This will display the assigned codes for all of the keys.

I noticed that the D-Pad changed on where it was located after changing that base file and running the gconftool command.

Only problem with comparing before and after is that it's not showing all of the keys for me but rather keys 55-255. I think maybe Xterm can't retain that lengthy of an output.

Any suggestions?

Also, any guess as to what the key "mode_switch" might do?

I've seen it assigned to key 255 before, but not right at this moment. I'm wondering if this could be a cause for some of the problems we're seeing.

One step closer I think.

Here's the same directories comparing Chinook's version (on the right) with Diablo.
/usr/share/X11/xkb/symbols/nokia_vndr/


After typing this in Xterm...
gconftool-2 --set -t bool /system/osso/af/keyboard-attached true && sleep 2 && gconftool-2 --set -t bool /system/osso/af/keyboard-attached false

I think that somehow changes the key symbols language it receives thereafter.

I'm not sure if this is possible, but is there a way to see what value or string the variable xkb_symbols has in Xterm?

I don't know the command line for this.

Thanks.