From kbfiltr perspective what differentiates uppercase and lowercase letters.
From analyzing the PKeyboard_Input_Data I have found they are identical with regards to the Makeid, Flags, Reserved and ExtraInformation.
yeah, they are identical, the operating system get the key ‘Caps Lock’ and ‘Shift’ state, then it translates the letter cases for applications.
xxxxx@edu.salford.ac.uk wrote:
From kbfiltr perspective what differentiates uppercase and lowercase letters.
From analyzing the PKeyboard_Input_Data I have found they are identical with regards to the Makeid, Flags, Reserved and ExtraInformation.
Right. Your keyboard does not have a lowercase R key and an uppercase R
key and a control R key. It simply has an R key. It’s up to the input
system to interpret what was meant by a keypress based on the modifier
keys that are also down (shift, ctrl, alt, caps lock, etc).
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
Right. Your keyboard does not have a lowercase R key and
an uppercase R key and a control R key. It simply has an R key.
Is the fact that you are having to explain this to a kernel developer not highly concerning to you? It is for me.
Interesting, at what level is this final determination made of uppercase/lowercase e.g. kbclass, i8042prt, user level etc.
the keyboard input processor in win32k.sys, which is the component that sends the reads to kbdclass.sys
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@edu.salford.ac.uk
Sent: Monday, July 6, 2015 6:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] letter cases kbfiltr
Interesting, at what level is this final determination made of uppercase/lowercase e.g. kbclass, i8042prt, user level etc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
user32!TranslateMessage I think
It translates WM_KEYUP/KEYDOWN (scancodes of some imaginary generic keyboard, usually 1-to-1 with real scancodes) to WM_CHAR (ABCD… etc).
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Interesting, at what level is this final determination made of uppercase/lowercase e.g. kbclass, i8042prt, user level etc.
>
Interesting in my kbfiltr I made variables for capslock and shift in my device extension so I could keep track of their states though I suppose it makes more sense to have it at a higher level.
> Is the fact that you are having to explain this to a kernel developer
not highly concerning to you? It is for me.
I feel it was a good question and received useful answers that are beneficial to many. Not everyones perspective is broad enough to understand how deep the i8042 controller workings are (still) ingrained into the kernel architecture to derive a simple answer.
In case you don’t know, it’s unfortunate the forum traffic here is going down and hostility towards newbies can be a major driver for that. I’ve seen such kill a very popular forum–nothing left but cranky old fogies berating newbies and just chat posting about the old days. Hope we can get less of that and more good technical discussions going like this one.
> Not everyones perspective is broad enough to understand how deep the i8042 controller
workings are (still) ingrained into the kernel architecture to derive a simple answer.
It has absolutely nothing to do with the i8042 controller - this is just the question of logical reasoning.
Let’s look at the whole thing from the perspective of someone who is capable of thinking logically but for some reason has never used a “conventional” computer. If pressing the same key may produce different results in different sutuations one does not really need to be some kind of Einstein in order to realize that the results that you see must depend on some additional factors,right. What may these factors be like? Once keyboard happens to be the only source of input to the kbdclass’s input queue, do you really think one needs to be a genius in order to realize that the distinction between the lower and upper cases for a given key must be somehow dependent on the keys that have been pressed earlier???
This is how someone who had never used a PC would think like. However, the OP apparently is not new to a PC, so that he must know (solely from the user’s perspective) that the case depends on the state of Shift and CapsLock keys. However, he is still “surprized” to see exactly the same scancodes for upper and lower case letters.
In other words, I am 100% with Chris here…
Anton Bassov
I understand and appreciate all the points you guys made. Can the moderator remove the thread.
I understand now. Thanks
Are there any other windows driver development forums that you guys could recommend that someone of my limited intelligence could use instead?
I know of Rohitab, any more?
> this is just the question of logical reasoning
Sure, logical reasoning from the stone age. Consider a hypothetical keyboard that sends characters, not 8042 scan codes from the 1970’s. Hence, it could send a chinese character, an uppercase R, or an lower case r for the same physical key being pressed. The user would never, ever have to go in to windows settings and manually configure what kind of keyboard he has or add new keyboards for other languages. A keyboard could paste macro text to the PC in any language. Users could remap keys and change languages using the keyboard and it would illuminate what the keys are instead of hard coded paint. No language indicator clutter bar would exist in the windows tray. THAT would be so much better and it’s a shame you can’t even envision anything like this. But never mind, go ahead and tell us how illogical this is and how the 1970’s method is so brilliant it will undoubtedly be used well into the 24th century. I would expect no less.
>Sure, logical reasoning from the stone age. Consider a hypothetical keyboard that sends
characters, not 8042 scan codes from the 1970’s.
Sorry, but we are not speaking about the relative merits and shortcomings of NT input archtecture, let alone about how the existing input devices of kbd class work, do we…
Anton Bassov
What you are speaking about is terminals of 1950-60-70ies, with rich UNIX legacy of them of /etc/termcap and other termios. And yes, pre-UNIX computers were also using them.
This - exactly your suggestion - is the stone age.
HID and scancodes (actually key numbers/HID usage numbers) are modernity.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
>> this is just the question of logical reasoning
>
> Sure, logical reasoning from the stone age. Consider a hypothetical keyboard that sends characters, not 8042 scan codes from the 1970’s. Hence, it could send a chinese character, an uppercase R, or an lower case r for the same physical key being pressed. The user would never, ever have to go in to windows settings and manually configure what kind of keyboard he has or add new keyboards for other languages. A keyboard could paste macro text to the PC in any language. Users could remap keys and change languages using the keyboard and it would illuminate what the keys are instead of hard coded paint. No language indicator clutter bar would exist in the windows tray. THAT would be so much better and it’s a shame you can’t even envision anything like this. But never mind, go ahead and tell us how illogical this is and how the 1970’s method is so brilliant it will undoubtedly be used well into the 24th century. I would expect no less.
>
>
You’re right–dumb terminals like the old 3270 sent character strings to the mainframe complete with upper and lower case r’s from the keyboard; no shift states, no scan codes. While this is one single similarity to the hypothetical approach I mention, I am certainly not advocating 3270 emulation BTW. However, your observation makes it all the more curious as to why people feel the need to get on the OP’s case for asking this question. There are different approaches and we all have to start somewhere to understand inner workings. The fact we aren’t all know it all’s is why this forum exists.