Board.KolibriOS.org

hidnplayr wrote:Did you update usbhid.obj ?

I recompiled the kernel after replacing "kernel/drivers/usbhid/keyboard.inc" (in which you replaced a zero by 56h).
The other files (such as usbhid.asm seemed unchanged).
What is usbhid.obj???

hidnplayr wrote:Please open the debug board in 'kernel' tab, and press the key that does not work.
What do you see?

When pressing the "<>\" key:
K: unclaimed HID input: usage=00070064, value=00000001
K: unclaimed HID input: usage=00070064, value=00000000

USBHID.obj is the USB driver for Human Interface Devices such as USB keyboard and mice.
The file "kernel/drivers/usbhid/keyboard.inc" does not affect kernel.mnt, but is part of this usb driver.
You can compile usbhid.asm from this folder manually and place it in kolibri.img in driver folder.
Or you can download latest kolibri.img from builds.kolibrios.org offcourse.

seppe wrote:Also the keymap needs some adjustments, but I will come back to that later.

Please find attached the "keyMap_BE" file.
It contains the 3 scancode tables (unshifted, shifted, AltGr) of 128 bytes each.
None existing scancodes get zero value.
None ASCII characters get the ascii code 0x11.
On receipt of ascii code 0x11, the aplication must use the scan code to take corresponding action.

Also attached:
A hex dump of the KeyMap_BE file.
A screendump of a kolibri application that displays ansi characters from the Window Latin code page 1252.

hidnplayr wrote:you can download latest kolibri.img from builds.kolibrios.org offcourse.

I downloaded the latest kolibri.img, and yes the "<>\" works. No problem with the "\".
Congratulations and thank you.

What about dead key handling (àòùìè âôîûê . . .)?
Should that not be part of the keyboard driver?

seppe wrote: Please find attached the "keyMap_BE" file.
It contains the 3 scancode tables (unshifted, shifted, AltGr) of 128 bytes each.
None existing scancodes get zero value.
None ASCII characters get the ascii code 0x11.
On receipt of ascii code 0x11, the aplication must use the scan code to take corresponding action.

I agree with your approach, it is what I have advocated for here.
The use of ASCII code 0x11 however looks strange to me, I'd personally prefer to use 0 (NULL) in this case also.

What fonts did you use to print symbols from codepage 1252?

About dead keys, I'm not sure how to properly handle them.
Putting this code in kernel seems like a good idea to me personally, but I'm no expert on the matter

PS: keep up the good work

hidnplayr wrote:About dead keys, I'm not sure how to properly handle them.
Putting this code in kernel seems like a good idea to me personally, but I'm no expert on the matter.

On my Belgian "Logitech" and "scanllon" USB keyboards all works perfect, except for dead keys.
I will start a new topic for dead keys because this keyboard feature is essential and concerns all countries.
In my opinion, it should be handled by the keyboard driver(s).

My 10 year old Apple USB keyboard gives unacceptible results. It probably needs a dedicated driver.
I have no idea if more recent apple keyboards would work fine.
Later I will do a test with an apple wireless keyboard (is wireless implemented in Kolibri???)

hidnplayr wrote:The use of ASCII code 0x11 looks strange to me, I'd personally prefer to use 0 (NULL) in this case also.

I choose 0x11 to indicate the valid keycombinations, and NULL for the invalid keycombinations (such as AltGr + letter).

Actually, all keyboard input handlers need to consider the control flags.
If the left Alt key or a ctrl key is pressed, the application should use the scancode and ignore the ASCII code.
If the right Alt key (AltGr) is pressed, the application should use the ASCII code (unless it is zero).

May I suggest that syscall 2 returns the controlkey flags in ebx.
This saves the application from making a syscall 66/3, and asures that the bits correspond to the moment that the key was pressed.

hidnplayr wrote:What fonts did you use to print symbols from codepage 1252?

A source embedded bitmap font 6x9 with a small personal touch, drawn with syscall 38 (line) with surprising speed.
Some time ago I made a suggestion for a systemcall to get/set the char and char2 tables, but i had no positive reactions.
See viewtopic.php?f=36&t=2690

seppe wrote:My 10 year old Apple USB keyboard gives unacceptible results. It probably needs a dedicated driver.
I have no idea if more recent apple keyboards would work fine.
Later I will do a test with an apple wireless keyboard (is wireless implemented in Kolibri???)

Wireless that uses a dedicated USB receiver should work, bluetooth etc. arent supported yet however.

seppe wrote:I choose 0x11 to indicate the valid keycombinations, and NULL for the invalid keycombinations (such as AltGr + letter).

AFAIK, this keymap is only used to assigned ASCII codes to Scan codes, thus it does not affect the returned scan codes.

seppe wrote: Actually, all keyboard input handlers need to consider the control flags.
If the left Alt key or a ctrl key is pressed, the application should use the scancode and ignore the ASCII code.
If the right Alt key (AltGr) is pressed, the application should use the ASCII code (unless it is zero).

May I suggest that syscall 2 returns the controlkey flags in ebx.
This saves the application from making a syscall 66/3, and asures that the bits correspond to the moment that the key was pressed.

Such changes to a system function that is used by almost all applications should be well figured out, if one does not want to rewrite all applications.
Perhaps a solution would be to make two additional keyboard modes (sysfn 66, 1) which will then enable returning the control keys in ebx on syscall 2.

seppe wrote: A source embedded bitmap font 6x9 with a small personal touch, drawn with syscall 38 (line) with surprising speed.
Some time ago I made a suggestion for a systemcall to get/set the char and char2 tables, but i had no positive reactions.
See viewtopic.php?f=36&t=2690

I think "the russians" do not want such change because they already have their CP866/CP1251 and thus aren't familiar with our problems.
Unicode seems the most sensible solution, on which everybody seems to agree.
There are several font renderers available for small system fonts, but nobody who wants to create all 100.000 glyphs by hand offcourse
viewtopic.php?f=36&t=1979
https://web.archive.org/web/20101129194 ... tu/mos/uc/ (http://mermaja.act.uji.es/docencia/is37 ... ernel_dev/)

Truetype fonts could be implemented on the application level (library) but should not be in kernel IMHO.
viewtopic.php?f=24&t=2059

hidnplayr wrote:I think "the Russians" do not want such change because they already have their CP866/CP1251 and thus aren't familiar with our problems.
Unicode seems the most sensible solution, on which everybody seems to agree.

In the early days, there was no Unicode.
Western Europeans had to work with code pages, cp1252 being the most popular.
I think that Kolibri will gain users when code pages are implemented while waiting for a future implementation of Unicode.
I will shortly post an application (my first kolibri application) that uses the cp1252.

Ok, good luck with it.

hidnplayr wrote:Ok, good luck with it.

I started a new topic for it, because it may be of interest to other Europeans : viewtopic.php?f=23&t=2696
There remain mistakes in the Belgian setup keymap:
Code "²³" is not generated and the "\" is missing on the "<>\" key.
This is fixed in the built-in keymap of my KeyView application.

Code "²³" is not generated and the "\" is missing on the "<>\" key.
Should be fixed now (altough I dont understand why '\' suddenly works).

hidnplayr wrote: Code "²³" is not generated and the "\" is missing on the "<>\" key.
Should be fixed now (altough I dont understand why '\' suddenly works).

I just installed the latest kolibri.img from the Build webpage. The fix does not work. (My mistake??).
Is there a way to verify the SVN version number?

An off topic question: When entering a message, many words are underlined in red. Is this a spellcheck?
If so, how to set it to English? Spreek jij nederlands?

I just installed the latest kolibri.img from the Build webpage. The fix does not work. (My mistake??).
Is there a way to verify the SVN version number?
You need to be more specific. What doesnt work? the ²³ key? (scancode 41) or the '\'.
It seems indeed that the '\' does not work, it worked once for me, but I havent figured out yet why it most of the times doesnt.

The SVN version of the kernel is printed on the blue screen, but the SVN version of an application would be hard to determine.

An off topic question: When entering a message, many words are underlined in red. Is this a spellcheck?
If so, how to set it to English? Spreek jij nederlands?
It's most likely the spell checker built into your browser, check your browser's settings.
(And install/activate additional dictionary for english if it's not already installed/activated)
Yes, I speak dutch, but there are little advantages of using it here in a public discussion.

hidnplayr wrote:The SVN version of the kernel is printed on the blue screen, but the SVN version of an application would be hard to determine.

Indeed, the startup screen shows: version 0.7.7.0+ [autobuild 24 may 2014 17:06, r4937].
So I should have your latest version.
Would it not be good practice to add the svn number in the source?

hidnplayr wrote:What doesnt work? the ²³ key? (scancode 41) or the '\'.

I isolated and Fasm compiled the BE keyboard alt table, and I give you the hex dump of it.
At location 0x56 there is a 0x3C; it should be 0x5C (\)
At location 0x12 there is a 0x65; it should be 0x80 (€)

geduld is de moeder van de computerwinkel

Ah yes, it seems I was looking at the wrong place in keymap for '\' symbol... updated once again (#4941)
I think all keys are mapped OK now.