vmware bochs osr5 under linux

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: OSR5 under bochs, Re: INT13 function FAh during boot?
Date: Thu, 16 May 2002 00:15:32 GMT
References: <200204271534.aa00201@xenitec.xenitec.on.ca> <20020427123740.A15678@mammoth.ca.caldera.com> <c12f3009.0205070848.7efda4d8@posting.google.com> <c12f3009.0205150741.259ed4cb@posting.google.com> 

Carl Sopchak wrote:

> Well, I've been working on the window size and multiscreen problems.
> 
> The solution that I am working on for the window size is to use a
> bigger font for the text-mode VGA emulation.  (That is, using a bigger
> X-Windows font to represent the standard font emulated.)  This is
> going pretty well, but there are a few issues that I need to clean up.
>  It involves modifying the bochs code to translate some sizes (window,
> cursor) between the emulated 8x16 VGA font and the 11x19 VGA font that
> I want to use.  (This 11x19 font is MUCH easier to read!)
> 
> I thought I had the multiscreen problem licked, by just changing the
> key map file (/usr/lib/keyboard/keys) so that <ctrl>1 switches to
> screen 1, <ctrl>2 to screen 2, etc.  This apparently worked, and had
> the apparent side effect of "undoing" the problem where Fn (unshifted)
> was switching screens.  I could think of no good reason for this side
> effect, but since it was desired, I didn't give it much thought...  
> ...Until today.  Now, pressing the unshifted number keys is switching
> the screen!  (Pressing either 2 or <ctrl>2 both switch screens, so the
> <ctrl> keypress is not toggling what OSR5 seems to think it's state
> is.)  I believe this all has to do with a bug in bochs, where the
> state of the shift keys is not being manipulated properly.

That's plausible...

> This leaves me with a few questions:
> 
> - How does the OSR5 console driver determine the state of the shift
> keys before it looks up what it should do in the keys file?

It tracks individual up/down state for all of the shift _keys_ (i.e. it
knows, or thinks it knows, whether Left-Ctrl is currently being held
down, independently of whether Right-Ctrl is currently being held down;
and so on).  It tracks these by the keyboard make/break codes.  Then,
obviously if any of the Ctrl keys are being held down at the moment,
Ctrl is in effect for the lookup in the keymap; etc.

The keyboard driver puts the keyboard in XT scancode mode (7-bit make
codes, break codes are make+0x80) by default.  AT scancode mode (8-bit
make codes, with something like "0xF0 make" as break code) is supported
by the code, but has various limitations that make it better to use XT
mode; besides, it won't go into AT mode without your explicitly setting
it up.  Linux probably defaults to AT mode and bochs probably captures
the make/break stream directly if it can, then translates it AT->XT for
OSR5, since OSR5 has programmed the virtual keyboard controller to XT
mode.  This may be a less tested code path of bochs since I would guess
most other hosted OSes use AT scancode mode by default.

> - How does OSR5 reset the keyboard?  (The bochs folks thought the way
> OSR5 recognised the presence of a disk was esoteric; maybe they think
> this keyboard reset method is as well [and have not implemented it
> yet].)

I'm not going to go look this up in the code right now, ask again if
other routes don't help...

> - I noticed in the bochs log that the LED status seems to be cleared. 
> Does OSR5 expect that these shift states are cleared at the same time?
>  (I haven't determined [yet] if bochs clears them...)

No, LEDs are programmed by OSR5 to reflect what it thinks the current
lock states are (which should generally be right since the lock states
it's going to apply are the ones it's tracking).  Programming the LEDs
isn't supposed to affect any state besides the visible state of the
LEDs.

>Bela<
 

Versatile Site Map Generator $59.00
A1 Sitemap Generator

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.