On August 6, 2001 10:53 am, Mike Andrew wrote:
> As an experiment only, you might try knocking out as many services and
> daemons as possible to pour the processing krunch into kde. It might not
> help one brass bit, but every indication is that the keyboard codes (not
> characters) are coming in too fast for a gui to handle. Linux does not use
> bios anything. Therefore all keycode translation is done by Linux. In the
> case of terms, they (generally) rely on the kernel itself whereas kde makes
> a meal of translating keystrokes into unicode before passing it thru an
> I18n (language) filter. In the case of konsole (eg) the reason why, it too,
> shows grabled characters is because kde is passing IT the char, because kde
> first needs to look for magic like alt F4 alt F2 etc.
hmn... could this buffer setting be part of the kernel config then?
> You could also knockout gpm. It can be nasty it's monitoring chars for it's
> clipboard.
gpm was one of the first things that I disabled.
> Point of sale readers generally have a binary that limits the character
> rate from them to the computer. I'll look at one tomorrow to see if it
> exhibits same behaviour and get back to you. Isn't there a windows app?
> that sets up this animal?
The device operated fine in windows.... and, don't ask me why I forgot this
(maybe I need more sleep or something), but the encrypted cuecat output
spewed out fine into kedit so perhaps not a buffer problem after all....
maybe disabling the encryption also turned off some sort of charactern rate
limitation set in the scanner.
I don't think the windows app would have any effect on the use of this device
in windows. AFAIK it simply picks up the output and tries to dig up
something on the website.
David Aikema
David Aikema
_______________________________________________
http://linux.nf -- [EMAIL PROTECTED]
Archives, Subscribe, Unsubscribe, Digest, Etc
->http://linux.nf/mailman/listinfo/linux-users
