linuxconsole-dev

Re: keyboard

[<ni...@co...>]

On Thu, Aug 31, 2000 at 05:17:14PM +0200, Vojtech Pavlik wrote:
> On Wed, Aug 30, 2000 at 03:25:23PM +0100, Antoine Martin wrote:
> > I guess that for multiple keyboards, the keyboard.c file from XFree86
> > will need changing,
> > anyone fancy making a patch to allow a ' Device "/dev/inputXXX" ' option
> > in XF86Config
> > for the keyboard section?
> 
> That would be very nice, yes. Noone has volunteered yet, afaik.
  I've started one.  Last I used it it worked 90% for my mouse.  I was
almost up to the point of creating the keyboard event maps when I stoped
working on it.
  It wouldn't be in the keyboard section, however. Not in XF4 at least. The
keyboard and mouse sections are depreciated and ideally shouldn't be used. 
But, as there is no suitible replacement for the old keyboard driver yet the
keyboard section is still needed.

> 
> > Or maybe X will start up using whatever keyboard was being used upon
> > start up?
> > Can someone explain briefly how that's going to work?
> > I will be looking at X docs today to try and understand a bit more about
> > drivers.
  Well, if the existing way (or something similar) that X gets it's
keycodes from the console survives then yes, it will use the same keyboard
config as that VC, unless overridden.

  - Nick Lopez
    kim...@at...
--
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler

Re: CVS updates/VGA mode setting

[Vojtech P. <vo...@su...>]

On Thu, Aug 31, 2000 at 11:30:04PM +0000, Petr Vandrovec wrote:
> On 31 Aug 00 at 23:01, Vojtech Pavlik wrote:
> > On Thu, Aug 31, 2000 at 06:36:08PM +0000, Petr Vandrovec wrote:
> > 
> > > If you want to support only standard modes (text, cfb8, vgaplanes, 
> > > vga8planes), it is easy. But there is couple of more or less nonstandard
> > > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
> > > character generator disabled (gives you `spectrum like' attribute + 8pixels).
> > > What to do with them? Let them fall through and report something similar
> > > for them?
> > 
> > The 1-line font (which you describe as spectrum-like) actually could be
> > quite useful for having a huge font, while still keeping minimum video
> > memory size.
> 
> Problem is that standard VGA can use only 64KB (VGA text compat.),
> or 128KB (when VGA hardware in real 4plane mode) in that mode, as planes
> 2 & 3 are reserved for character generator and unused... This
> limits you to either 80x409 (~ 640x409) or 80x819 (or 100x655 (~800x655))... 

This is just fine for 80x25 text w/ unlimited font ... (80x25 is
720x400, assuming 9-bit mode).

> This is not too much - it is same as 4plane modes (real textmode with
> 8x16 font gives you virtual screen 640x6544, BTW).
> 
> And unfortunately, although bmove works on same speed as in 4plane mode,
> putc/putcs are much slower, as you cannot use special VGA write modes :-(
> 16 writes in 128KB mode, instead of 8 for 4plane...
>                                                  Best regards,
>                                                     Petr Vandrovec
>                                                     van...@vc...
>                                                     

-- 
Vojtech Pavlik
SuSE Labs

Re: CVS updates/VGA mode setting

[Petr V. <VAN...@vc...>]

On 31 Aug 00 at 23:01, Vojtech Pavlik wrote:
> On Thu, Aug 31, 2000 at 06:36:08PM +0000, Petr Vandrovec wrote:
> 
> > If you want to support only standard modes (text, cfb8, vgaplanes, 
> > vga8planes), it is easy. But there is couple of more or less nonstandard
> > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
> > character generator disabled (gives you `spectrum like' attribute + 8pixels).
> > What to do with them? Let them fall through and report something similar
> > for them?
> 
> The 1-line font (which you describe as spectrum-like) actually could be
> quite useful for having a huge font, while still keeping minimum video
> memory size.

Problem is that standard VGA can use only 64KB (VGA text compat.),
or 128KB (when VGA hardware in real 4plane mode) in that mode, as planes
2 & 3 are reserved for character generator and unused... This
limits you to either 80x409 (~ 640x409) or 80x819 (or 100x655 (~800x655))... 
This is not too much - it is same as 4plane modes (real textmode with
8x16 font gives you virtual screen 640x6544, BTW).

And unfortunately, although bmove works on same speed as in 4plane mode,
putc/putcs are much slower, as you cannot use special VGA write modes :-(
16 writes in 128KB mode, instead of 8 for 4plane...
                                                 Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

Re: CVS updates/VGA mode setting

[Vojtech P. <vo...@su...>]

On Thu, Aug 31, 2000 at 06:36:08PM +0000, Petr Vandrovec wrote:

> If you want to support only standard modes (text, cfb8, vgaplanes, 
> vga8planes), it is easy. But there is couple of more or less nonstandard
> modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
> character generator disabled (gives you `spectrum like' attribute + 8pixels).
> What to do with them? Let them fall through and report something similar
> for them?

The 1-line font (which you describe as spectrum-like) actually could be
quite useful for having a huge font, while still keeping minimum video
memory size.

-- 
Vojtech Pavlik
SuSE Labs

Re: CVS updates/VGA mode setting

[<jmc...@li...>]

James Simmons <jsi...@ac...> wrote:
> About as many that support VESA 2.0. I have 6 video cards and not one
> supports VESA 2.0. Even fewer support VESA 3.0. Yes their is a VESA 3.0
> standard that allows nice things like changing the video mode after boot
> time via BIOS calls in protect mode.

	I once wrote a device driver for Linux that used the
VESA 3 protected mode code, but it wouldn't work for
setting video modes for ANY card that advertised itself
as VESA 3. This was in Spring '99, and things may have changed
since then, but I doubt it. 

	A contact I had at SciTech said that the problem lay in the
fact that there were NO commercially availible testing suites for the 
VESA 3.0 protect mode spec.

	(You can get my code at: http://zhrodague.net/~jmcc/vesa3/ )

-- 
Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax
jmc...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: CVS updates/VGA mode setting

[Petr V. <VAN...@vc...>]

On 31 Aug 00 at 9:18, James Simmons wrote:
> > > Nice. Support even for Mode X :-) I will take a look at it in depth. The
> > 
> > Yes. And it even works...
> 
> Great. Will merge with CVS code soon. 

Thanks.
 
> > Problem is that for example Matrox devices are totaly dead after powerup.
> > And enabling framebuffer region and accessing it can cause PCI bus lockup,
> > because of memory clock (on old Millennium I) are programmed for 0Hz,
> > so PCI read cycle never finish.
> 
> What I mean is read the values from the vga hardware instead of from
> screeninfo which is provided by the firmware. 

If you want to support only standard modes (text, cfb8, vgaplanes, 
vga8planes), it is easy. But there is couple of more or less nonstandard
modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
character generator disabled (gives you `spectrum like' attribute + 8pixels).
What to do with them? Let them fall through and report something similar
for them?

If you are talking only about recognition of currently used videomode
at startup, it should be possible, and possibly trivial. I have
(in mgadump) code which adds `correct' constants and sums correct
bits together to get all picture sizes... Should I port that code
to Linux and send it to you?
                                                    Petr
                                                    

Re: keyboard

[Vojtech P. <vo...@su...>]

On Wed, Aug 30, 2000 at 03:25:23PM +0100, Antoine Martin wrote:

> newbie to ruby,
> (I follow the linuxconsole mailing list regularly, but that was not
> enough I am afraid)
> 
> I had to remove a line preventing util/inputattach.c from working.
> (but didn't want to update in cvs as I dunno who's changing what)
> offending line:
> # { "--stinger",          "-sting",       B1200,
> CS8,                     SERIO_STINGER,  0x00,   1,      stinger_init },
> 
> SERIO_STINGER not defined.

ruby/linux/include/linux/serio.h, line 106:

#define SERIO_STINGER   0x1e

> with 2.40-test7 + patched:
> make menuconfig wouldn't work as is (it complained about include/asm
> being a directory or
> whatever so I changed the makefile and removed the rm -f include/asm -
> maybe it should
> be a rm -rf ?)

Yes.

> Is devfs required/advisable/not needed?

Works both with and without.

> I could test my usb keyboard with evtest, but there is only one event
> interface
> where is my ps2 keyboard (as a device)?

/dev/input/eventX, as well, but perhaps you didn't enable all the needed
options.

> How do I set the multiplexing?
> btw, linux refuses to boot sometimes when my usb keyboard is plugged
> (stops after you press return in lilo) but if I unplug and then replug
> after the boot it's fine..

That's a bug in the current USB (not ruby) code.

> I guess that for multiple keyboards, the keyboard.c file from XFree86
> will need changing,
> anyone fancy making a patch to allow a ' Device "/dev/inputXXX" ' option
> in XF86Config
> for the keyboard section?

That would be very nice, yes. Noone has volunteered yet, afaik.

> Or maybe X will start up using whatever keyboard was being used upon
> start up?
> Can someone explain briefly how that's going to work?
> I will be looking at X docs today to try and understand a bit more about
> drivers.

-- 
Vojtech Pavlik
SuSE Labs

Re: keyboard

[Antoine M. <an...@go...>]

James Simmons wrote:

> > SERIO_STINGER not defined.
> Strange. I gave it a run and had no problem. Is this with the current CVS?

It was fixed within a few hours... (I had also sent a mail fo Vojtech)

> Also make sure /usr/include/linux points to the ruby tree. I have made
> this mistake before.

So have I ;-) but not this time.

> So include/asm
> should be a symbolic link. Normally make config sets this symbolic link.
> Remove the include/asm diretcory and rerun make menuconfig. I'm curious.

yep, it is a softlink.
Ok, I'll try that later. (can't do it in the office as they are all live
systems...)

> You wouldn't happen to be running a Debian distro?

no, I am running an old slackware, updated a zillion times.

>
> > I could test my usb keyboard with evtest, but there is only one event
> > interface
> > where is my ps2 keyboard (as a device)?
>
> What do you see for your dmesg? I have
>
> (...)

> This is for a single PS/2 keyboard. What do you see for your setup?

similar stuff. I'll send the logs later if needed.
but from what you said below, I understand it means that my primary
keyboard (ps2) is bound to the console and won't be in /dev/input/event,
is this correct?

>
> > How do I set the multiplexing?
>
> The way ruby works is one keyboard is mapped to one display for the
> console system. If you want to access non attached keyboard this is where
> the input interface comes in. By non attached I mean you have more
> keybaords than displays (like me). Once the kernel side is pretty much
> done I will begain work on a new consd deamon that will be able to do
> weird combos like VTs with 2 keyboards and one display. That will be
> handled in userland. As for multiple VTs the console system handles the
> multiplexing for you :-)
>

Actually, I have 2 displays (rage128 agp and g200 pci), 2 keyboards (ps2
and usb) and 2 rodents (ps2 and usb).
And I wouldn't mind running concurrently 2 full X desktops off 1 box...
(could even run q3 multiplayer off that box!?)
When I start 2 X servers (both using the ps2 keyboard since I couldn't
work it out) I need to VT switch to change which X is active, I guess
tha's because they share the same keyboard. If I get one of the Xs to use
the usb keyboard, will they both be running concurrently then? Or do I need
something extra...

Also, when using ruby, it boots off the g200 (usually boots off the r128)
and the kernel boot messages in dmesg do not contain whatever was
on the console before it switched to the g200, where can I get these early
messages? And why did they disappear!?
Are there any boot parameters to set the console to the r128 instead?
(I tried lilo append "atyfb:....." but it still went to the g200)
Then, if I try to con2fb to the r128, it does not come on (but it works on
test7).
Framebuffer tools (fbset, fbi or fbtv...) all go to the g200, even when I
specify
-c /dev/fb1 (the r128), now that's scary!
Also, on test7 I need to con2fb to the r128 before I can use it as a
framebuffer
device (all modules already loaded...), otherwise the fb mode that gets set is

incorrect and data only appears at the top of the screen (higher res).

> > I guess that for multiple keyboards, the keyboard.c file from XFree86
> > will need changing,
> > anyone fancy making a patch to allow a ' Device "/dev/inputXXX" ' option
> > in XF86Config
> > for the keyboard section?
>
> Look at ruby CVS code for xfree86.

Where is this tree?

> It has a patch to apply against the
> XFree86 3.3.6 code tree. As far as I can see XF4.0 isn't support yet with
> the CVS code. XF4.0 does have support for multiple keybaords but last I
> looked it didn't support USB keyboards or /dev/input. Which X server are
> you running.

4.0.1 from CVS (but I must have an old 3.3.6 tree somewhere)

> Depends on which X server you have. For XFree86 3.3.6 you have to apply a
> patch. For XF4.0 you play some config tricks to get it to work. From the
> last I seen USB keyboards and the new input system are not supported with
> XF4.0. With XFree86 it usually takes them 6 months to support something.

what about doing it myself?
I was looking around for docs on xinput and the whole input stuff in X4...
and I didn't find much info.

Thanks for your help, it already makes a lot more sense.

Antoine

RE: CVS updates/VGA mode setting

[James S. <jsi...@ac...>]

> > True. It would be a pain to make vgacon work with other vgacon drivers. It
> > is no problem with another fbcon or mdacon driver.
> 
> The VBE 3 spec. does make some allotment for dual card systems.  It allows
> for relocation of the video BIOS and the second card would act as a slave to
> the primary card.  So in theory, two video cards should be able to be
> supported via vgacon.  The question is, how many cards actually support VBE
> 3?

About as many that support VESA 2.0. I have 6 video cards and not one
supports VESA 2.0. Even fewer support VESA 3.0. Yes their is a VESA 3.0
standard that allows nice things like changing the video mode after boot
time via BIOS calls in protect mode.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: CVS updates/VGA mode setting

[James S. <jsi...@ac...>]

> > Nice. Support even for Mode X :-) I will take a look at it in depth. The
> 
> Yes. And it even works...

Great. Will merge with CVS code soon. 

> > one thing I like to see is vgacon set the video mode itself instead of
> > depending on the system firmware. The reason being is usually firmware is 
> 
> Problem is that for example Matrox devices are totaly dead after powerup.
> And enabling framebuffer region and accessing it can cause PCI bus lockup,
> because of memory clock (on old Millennium I) are programmed for 0Hz,
> so PCI read cycle never finish.

What I mean is read the values from the vga hardware instead of from
screeninfo which is provided by the firmware. 

Re: keyboard

[James S. <jsi...@ac...>]

> I had to remove a line preventing util/inputattach.c from working.
> (but didn't want to update in cvs as I dunno who's changing what)
> offending line:
> # { "--stinger",          "-sting",       B1200,
> CS8,                     SERIO_STINGER,  0x00,   1,      stinger_init },
> 
> SERIO_STINGER not defined.

Strange. I gave it a run and had no problem. Is this with the current CVS?
SERIO_STINGER is defined in serio.h in linux/include/linux. Please try it
again with the latest CVS and let me know if you have the same problem.
Also make sure /usr/include/linux points to the ruby tree. I have made
this mistake before.

> with 2.40-test7 + patched:
> make menuconfig wouldn't work as is (it complained about include/asm
> being a directory or
> whatever so I changed the makefile and removed the rm -f include/asm -
> maybe it should
> be a rm -rf ?)

That is also strange. Normally include/asm is a symbolic link to
include/asm-xxx where xxx is the platform you are on. So include/asm
should be a symbolic link. Normally make config sets this symbolic link. 
Remove the include/asm diretcory and rerun make menuconfig. I'm curious. 
You wouldn't happen to be running a Debian distro?
 
> Is devfs required/advisable/not needed?

Same as any other system. It is not needed but if you do use devfs
remember to run the devfsd deamon. 

> I could test my usb keyboard with evtest, but there is only one event
> interface
> where is my ps2 keyboard (as a device)?

What do you see for your dmesg? I have

Aug 29 13:05:52 maxwell kernel: keyboard.c: Adding keyboard: input0
Aug 29 13:05:52 maxwell kernel: input0: AT Set 2 Extended keyboard
Aug 29 13:05:52 maxwell kernel:  on serio0
Aug 29 13:05:52 maxwell kernel: mice: PS/2 mouse device common for all
mice
Aug 29 13:05:52 maxwell kernel: event0: Event device for input0

This is for a single PS/2 keyboard. What do you see for your setup?

> How do I set the multiplexing?

The way ruby works is one keyboard is mapped to one display for the
console system. If you want to access non attached keyboard this is where
the input interface comes in. By non attached I mean you have more
keybaords than displays (like me). Once the kernel side is pretty much
done I will begain work on a new consd deamon that will be able to do
weird combos like VTs with 2 keyboards and one display. That will be
handled in userland. As for multiple VTs the console system handles the
multiplexing for you :-) 

> btw, linux refuses to boot sometimes when my usb keyboard is plugged
> (stops after you press return in lilo) but if I unplug and then replug
> after the boot it's fine..

That sounds like a BIOS problem. I have the same problem with plugging in
2 ps/2 keyboards. It confuses the BIOS. I have to plug in my second PS/2
keyboard while the kernel is booting. I might be wrong as I don't have a
usb keyboard. 

> I guess that for multiple keyboards, the keyboard.c file from XFree86
> will need changing,
> anyone fancy making a patch to allow a ' Device "/dev/inputXXX" ' option
> in XF86Config
> for the keyboard section?

Look at ruby CVS code for xfree86. It has a patch to apply against the
XFree86 3.3.6 code tree. As far as I can see XF4.0 isn't support yet with
the CVS code. XF4.0 does have support for multiple keybaords but last I
looked it didn't support USB keyboards or /dev/input. Which X server are
you running. 

> Or maybe X will start up using whatever keyboard was being used upon
> start up?
> Can someone explain briefly how that's going to work?
> I will be looking at X docs today to try and understand a bit more about
> drivers.

Depends on which X server you have. For XFree86 3.3.6 you have to apply a
patch. For XF4.0 you play some config tricks to get it to work. From the 
last I seen USB keyboards and the new input system are not supported with
XF4.0. With XFree86 it usually takes them 6 months to support something.

RE: CVS updates/VGA mode setting

[Brad D. <Br...@NE...>]

> >   Although I think that we should leave VGA alone. It is just too
painful
> > to try multihead on such hardware...
>
> True. It would be a pain to make vgacon work with other vgacon drivers. It
> is no problem with another fbcon or mdacon driver.

The VBE 3 spec. does make some allotment for dual card systems.  It allows
for relocation of the video BIOS and the second card would act as a slave to
the primary card.  So in theory, two video cards should be able to be
supported via vgacon.  The question is, how many cards actually support VBE
3?

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

Re: CVS updates/VGA mode setting

[Petr V. <VAN...@vc...>]

On 30 Aug 00 at 8:04, James Simmons wrote:
> > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/2.4.0-test7-vgatext.gz.
> > It contains patch for 2.4.0-test7 which adds textmode and 8bpp modes
> > to vga16fb driver (8bpp of course only 320x200 cfb8 or 360x480 planar 8,
> > as standard VGA knows).
> 
> Nice. Support even for Mode X :-) I will take a look at it in depth. The

Yes. And it even works...

But 'cfb4' code (yes, even such thing is possible on VGA) works only
on some hardware... On other hardware you can have swapped even and
odd pixel columns (swapped nibbles in byte...). If memory serves correctly,
current version works on ATI chips, but does not on Matrox and C&T products.

> one thing I like to see is vgacon set the video mode itself instead of
> depending on the system firmware. The reason being is usually firmware is 

Problem is that for example Matrox devices are totaly dead after powerup.
And enabling framebuffer region and accessing it can cause PCI bus lockup,
because of memory clock (on old Millennium I) are programmed for 0Hz,
so PCI read cycle never finish.

                                        Petr
                                        

keyboard

[Antoine M. <an...@go...>]

newbie to ruby,
(I follow the linuxconsole mailing list regularly, but that was not
enough I am afraid)

I had to remove a line preventing util/inputattach.c from working.
(but didn't want to update in cvs as I dunno who's changing what)
offending line:
# { "--stinger",          "-sting",       B1200,
CS8,                     SERIO_STINGER,  0x00,   1,      stinger_init },

SERIO_STINGER not defined.

with 2.40-test7 + patched:
make menuconfig wouldn't work as is (it complained about include/asm
being a directory or
whatever so I changed the makefile and removed the rm -f include/asm -
maybe it should
be a rm -rf ?)

Is devfs required/advisable/not needed?

I could test my usb keyboard with evtest, but there is only one event
interface
where is my ps2 keyboard (as a device)?
How do I set the multiplexing?
btw, linux refuses to boot sometimes when my usb keyboard is plugged
(stops after you press return in lilo) but if I unplug and then replug
after the boot it's fine..

I guess that for multiple keyboards, the keyboard.c file from XFree86
will need changing,
anyone fancy making a patch to allow a ' Device "/dev/inputXXX" ' option
in XF86Config
for the keyboard section?
Or maybe X will start up using whatever keyboard was being used upon
start up?
Can someone explain briefly how that's going to work?
I will be looking at X docs today to try and understand a bit more about
drivers.

Please help me help you.
Thanks
Antoine

Re: New VGA console coming

[James S. <jsi...@ac...>]

> If you'll insist on 8x16 font (16 bytes per character) and only 65536
> characters, it is 1MB only... Yes, if you want different character
> sets (different font slices) on each VT, it can get memory consuming,
> but in such case - create kernel thread which will have access to
> swappable memory and swap unused characters out. Or leave whole
> font delivery on userspace...

Yeap. It should be handled as much as possible in userspace. I believe we
should allow only one font type per VT at boot time. If possible share 
that font with as many VTs as possible. This way we can use COW techniques
to save on memory consumation. In fact the new code in CVS points works
this way. I have a default font in struct vt_struct and every vc_data that
is attached to that vt_stuct have its own font point pointing to the
default font. When userland changes this then the pointer will point to
the new font. If the user uses the default font which is the most common
case then only one copy of the font exist in memory for all those VCs.

> I do not think that font cache idea is best... Leave it on user - if he
> has hardware which is not capable of displaying more than 512 different
> characters simultaneously, give him two choices:
> (1) select which 512 characters he'll use or
> (2) limit his screen to 512 characters only and change character generator
>     instead of screen contents

True if it is a harware limitation. If it is not then its gets a little
tricky. Maybe all we need is 512 to get threw the boot process for w_char
based languages. After boot time let userland handle it. 

> Yes, shadow buffer layout needs to be changed. Do not forget Martin Mares
> ideas when doing it - currently slowest thing during screen scroll is
> shifting buffer in memory. Having array of pointers to lines can
> make this operation much faster.

Interesting idea. Also what is really slow is bmove. Inserting a character
and moving all the characters to the left of it can be pretty tricky. The
thing I never understood is way the shadow buffer is the exact same size
as the visible area of the display. Why not make it bigger and just move a
pointer in the shadow buffer. We can 99% of the time use harware panning
to move the characters up and then just read the buffer further down in
the buffer to display them. Yes sooner or later we have to flip this
shadow buffer.  

> For character, either make it 4:4:24, where
> first 4=one of 16 currently selected colors,
>       4=one of 16 currently selected colors,
>      24=character number; either Unicode 0-10FFFF, or arbitrary font
> encoding..., 

This is closer to what is really needed. We also need a byte for
attributes. Maybe we can squeeze it in 4 bits. This will consume less
memory as you pointed out.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: CVS updates/VGA mode setting

[James S. <jsi...@ac...>]

> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/2.4.0-test7-vgatext.gz.
> It contains patch for 2.4.0-test7 which adds textmode and 8bpp modes
> to vga16fb driver (8bpp of course only 320x200 cfb8 or 360x480 planar 8,
> as standard VGA knows).

Nice. Support even for Mode X :-) I will take a look at it in depth. The
one thing I like to see is vgacon set the video mode itself instead of
depending on the system firmware. The reason being is usually firmware is 
not multihead freindly and also this will allow use to be able to migrate
between vgacon and another console subsystem like fbdev. We can also use
this for recovery when a app like a X server crashes. 

>   Although I think that we should leave VGA alone. It is just too painful
> to try multihead on such hardware...

True. It would be a pain to make vgacon work with other vgacon drivers. It
is no problem with another fbcon or mdacon driver.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: CVS updates/VGA mode setting

[James S. <jsi...@ac...>]

Now it is in sync :-) Sorry. I lost teh connect while syncing my tree with
the cvs tree. I hoped it got threw but didn't. Now all is fine. I also
tested this tree. Workes great.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: New VGA console coming

[Petr V. <van...@vc...>]

On Sun, Aug 27, 2000 at 10:26:55AM -0400, James Simmons wrote:
> > > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads
> > > to me to believe it might be possible for VGA to support double byte
> > > fonts. This of course would mean a rethinking of how the shadow buffer
> > > should be done. Any ideas anyone?
> 
> It is there. Int 10/AH=18h. Their is also a AH=19h (Japanese VIDEO -
> DOUBLE-BYTE CHARACTER SET SHIFT). Not much info tho :-( As for the 
> text modes (mode 52h) that support 16 bit characters appears to be
> actually vga 16 color graphics modes. I still like to know where those
> extra fonts are stored. Maybe in regular memory. We do have vgafb which

If you'll insist on 8x16 font (16 bytes per character) and only 65536
characters, it is 1MB only... Yes, if you want different character
sets (different font slices) on each VT, it can get memory consuming,
but in such case - create kernel thread which will have access to
swappable memory and swap unused characters out. Or leave whole
font delivery on userspace...

> could be made to support 16 bit characters. Since vgafb is supported on 
> any platform that vgacon is this expands the range of languages linux can
> support. The only problem is ...
 
> ... how to handle so many fonts. I like the idea of a cache of X amount of
> characters. Even for fbcon this would be useful. As for the layout of the
> shadow buffer. We really need to reconsider its layout. With the idea of
> a font cache how about this. 16 bits is used to represent each character. 
> The high 8 bits are a index to different font caches. This allows 256
> different font caches. The lower 8 bits acts as a index into the font
> cache. Now what to do with the attributes? The idea of having 24 bits to
> represent a text charachter botehrs me. I prefere if it was 32 bits. We
> have to do alot of shifting bits around to get to work otherwise. 

I do not think that font cache idea is best... Leave it on user - if he
has hardware which is not capable of displaying more than 512 different
characters simultaneously, give him two choices:
(1) select which 512 characters he'll use or
(2) limit his screen to 512 characters only and change character generator
    instead of screen contents

Yes, shadow buffer layout needs to be changed. Do not forget Martin Mares
ideas when doing it - currently slowest thing during screen scroll is
shifting buffer in memory. Having array of pointers to lines can
make this operation much faster.

For character, either make it 4:4:24, where
first 4=one of 16 currently selected colors,
      4=one of 16 currently selected colors,
     24=character number; either Unicode 0-10FFFF, or arbitrary font
encoding..., or, if you want, 32:32:32:32,
where 32=reserved,
      32=foreground color, 8:8:8:8 RGBA or 16:5:6:5 or 24unused:8 or...
      32=background color,
      32=character number
I do not think that anything else is reasonable. And do not forget that
for 32:32:32:32 one on-screen character consumes 16 bytes, 80x25 screen
then consuming 32K instead of current 4KB...
					Petr Vandrovec
					van...@vc...

Re: CVS updates/VGA mode setting

[Petr V. <van...@vc...>]

On Sat, Aug 26, 2000 at 11:24:30PM -0400, James Simmons wrote:
> The second thing which I forgot to mention. I also am going to be working
> on getting vgacon to set the mode independent of using anything like the
> BIOS. This will allow more portablity and make it more multihead friendly. 
> Thsi will also allow the ability to move between different console drivers
> like fbcon and vgacon. With the current tree you can only go from vgacon
> to fbcon. I plan to make the reverse true. This will also allow recovery
> when userland apps don't reset the hardware properly. Now vagcon can reset
> the hardware it's self. 

Hi James,
  if you want, you can take a look at 
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/2.4.0-test7-vgatext.gz.
It contains patch for 2.4.0-test7 which adds textmode and 8bpp modes
to vga16fb driver (8bpp of course only 320x200 cfb8 or 360x480 planar 8,
as standard VGA knows).
  Text mode support only 256 characters, but if there are request to
change it... Also, hardware VGA cursor is not utilized. This patched
driver uses vga_io_{r,w} macros to access hardware registers. So converting
to vga_mm_{r,w} or to pure vga_{r,w} should not be too hard.
  Although I think that we should leave VGA alone. It is just too painful
to try multihead on such hardware...
					Best regards,
						Petr Vandrovec
						van...@vc...

P.S.: I'm using this vga16fb to get 800x592 textmode on my notebook.
Fortunately my LCD does not care about screen refresh...

Re: CVS updates/VGA mode setting

[Christoph H. <hc...@ca...>]

> The CVS has been brought into sync with test7.

Not completly - you missed some updates. Here's the diff:

	Christoph


Index: linux/arch/sparc64/config.in
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/arch/sparc64/config.in,v
retrieving revision 1.5
diff -u -r1.5 config.in
--- linux/arch/sparc64/config.in	2000/08/11 00:16:02	1.5
+++ linux/arch/sparc64/config.in	2000/08/27 18:32:45
@@ -81,24 +81,29 @@
 
 bool 'Normal floppy disk support' CONFIG_BLK_DEV_FD
 
-bool 'Multiple devices driver support' CONFIG_BLK_DEV_MD
-if [ "$CONFIG_BLK_DEV_MD" = "y" ]; then
-   tristate '  Linear (append) mode' CONFIG_MD_LINEAR
-   tristate '  RAID-0 (striping) mode' CONFIG_MD_STRIPED
-#   tristate '  RAID-1 (mirroring) mode' CONFIG_MD_MIRRORING
-#   tristate '  RAID-4/RAID-5 mode' CONFIG_MD_RAID5
-fi
+tristate 'Loopback device support' CONFIG_BLK_DEV_LOOP
+dep_tristate 'Network block device support' CONFIG_BLK_DEV_NBD $CONFIG_NET
+
+#tristate 'Logical volume manager (LVM) support' CONFIG_BLK_DEV_LVM N
+#if [ "$CONFIG_BLK_DEV_LVM" != "n" ]; then
+#   bool '   LVM information in proc filesystem' CONFIG_LVM_PROC_FS Y
+#fi
+
+tristate 'Multiple devices driver support' CONFIG_BLK_DEV_MD
+dep_tristate '  Linear (append) mode' CONFIG_MD_LINEAR $CONFIG_BLK_DEV_MD
+dep_tristate '  RAID-0 (striping) mode' CONFIG_MD_RAID0 $CONFIG_BLK_DEV_MD
+dep_tristate '  RAID-1 (mirroring) mode' CONFIG_MD_RAID1 $CONFIG_BLK_DEV_MD
+#dep_tristate '  RAID-4/RAID-5 mode' CONFIG_MD_RAID5 $CONFIG_BLK_DEV_MD
+#if [ "$CONFIG_MD_LINEAR" = "y" -o "$CONFIG_MD_RAID0" = "y" -o "$CONFIG_MD_RAID1" = "y" -o "$CONFIG_MD_RAID5" = "y" ]; then
+#        bool '  Boot support' CONFIG_MD_BOOT
+#        bool '  Auto Detect support' CONFIG_AUTODETECT_RAID
+#fi
 
 tristate 'RAM disk support' CONFIG_BLK_DEV_RAM
 if [ "$CONFIG_BLK_DEV_RAM" = "y" -o "$CONFIG_BLK_DEV_RAM" = "m" ]; then
 	int '   Default RAM disk size' CONFIG_BLK_DEV_RAM_SIZE 4096
 fi
-if [ "$CONFIG_BLK_DEV_RAM" = "y" ]; then
-   bool '  Initial RAM disk (initrd) support' CONFIG_BLK_DEV_INITRD
-fi
-
-tristate 'Loopback device support' CONFIG_BLK_DEV_LOOP
-tristate 'Network block device support' CONFIG_BLK_DEV_NBD
+dep_bool '  Initial RAM disk (initrd) support' CONFIG_BLK_DEV_INITRD $CONFIG_BLK_DEV_RAM
 
 endmenu
 
@@ -226,9 +231,10 @@
    if [ "$CONFIG_NETDEVICES" = "y" ]; then
       tristate '  Dummy net driver support' CONFIG_DUMMY
       tristate '  Bonding driver support' CONFIG_BONDING
+      tristate '  Universal TUN/TAP device driver support' CONFIG_TUN
       if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
         if [ "$CONFIG_NETLINK" = "y" ]; then
-          tristate '  Ethertap network tap (EXPERIMENTAL)' CONFIG_ETHERTAP
+          tristate '  Ethertap network tap (OBSOLETE)' CONFIG_ETHERTAP
         fi
       fi
       tristate '  PPP (point-to-point) support' CONFIG_PPP
Index: linux/drivers/Makefile
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- linux/drivers/Makefile	2000/08/11 00:16:02	1.4
+++ linux/drivers/Makefile	2000/08/27 18:32:45
@@ -7,7 +7,7 @@
 #
 # Note 2! The CFLAGS definitions are now in the main makefile.
 
-SUB_DIRS     := block char net parport sound misc
+SUB_DIRS     := block char net parport sound misc media
 MOD_SUB_DIRS := $(SUB_DIRS)
 ALL_SUB_DIRS := $(SUB_DIRS) pci sgi ide scsi sbus cdrom isdn pnp i2o \
 				ieee1394 macintosh video dio zorro fc4 \
Index: linux/drivers/char/Config.in
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/char/Config.in,v
retrieving revision 1.13
diff -u -r1.13 Config.in
--- linux/drivers/char/Config.in	2000/08/11 00:16:02	1.13
+++ linux/drivers/char/Config.in	2000/08/27 18:32:46
@@ -6,10 +6,10 @@
 
 bool 'Virtual terminal' CONFIG_VT
 if [ "$CONFIG_VT" = "y" ]; then
-   define_bool CONFIG_VT_EXTENDED y	
-   define_bool CONFIG_INPUT y	
+   define_bool CONFIG_VT_EXTENDED y
+   define_bool CONFIG_INPUT y
    bool '  Support for console on virtual terminal' CONFIG_VT_CONSOLE
-#  if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
 #     bool '  Extended terminal emulation (EXPERIMENTAL)' CONFIG_VT_EXTENDED
 #     bool '  DEC ReGIS graphics support (EXPERIMENTAL)' CONFIG_VT_DEC_REGIS
 #     bool '  DEC Sixel graphics support (EXPERIMENTAL)' CONFIG_VT_DEC_SIXEL
@@ -18,8 +18,7 @@
 #     bool '  ISO6429 bidirectional support (EXPERIMENTAL)' CONFIG_VT_BDSM
 #  fi
 fi
-
-tristate 'Standard/generic (dumb) serial support' CONFIG_SERIAL
+tristate 'Standard/generic (8250/16550 and compatible UARTs) serial support' CONFIG_SERIAL
 if [ "$CONFIG_SERIAL" = "y" ]; then
    bool '  Support for console on serial port' CONFIG_SERIAL_CONSOLE
    if [ "$CONFIG_ARCH_ACORN" = "y" ]; then
@@ -71,6 +70,15 @@
      tristate '    Stallion EC8/64, ONboard, Brumby support' CONFIG_ISTALLION
    fi
 fi
+if [ "$CONFIG_FOOTBRIDGE" = "y" ]; then
+   bool 'DC21285 serial port support' CONFIG_SERIAL_21285
+   if [ "$CONFIG_SERIAL_21285" = "y" ]; then
+      if [ "$CONFIG_OBSOLETE" = "y" ]; then
+         bool '  Use /dev/ttyS0 device (OBSOLETE)' CONFIG_SERIAL_21285_OLD
+      fi
+      bool '  Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE
+   fi
+fi
 bool 'Unix98 PTY support' CONFIG_UNIX98_PTYS
 if [ "$CONFIG_UNIX98_PTYS" = "y" ]; then
    int 'Maximum number of Unix98 PTYs in use (0-2048)' CONFIG_UNIX98_PTY_COUNT 256
@@ -113,8 +121,9 @@
    tristate '  Software Watchdog' CONFIG_SOFT_WATCHDOG
    tristate '  Berkshire Products PC Watchdog' CONFIG_PCWATCHDOG
    tristate '  Acquire SBC Watchdog Timer' CONFIG_ACQUIRE_WDT
-   tristate '   SBC-60XX Watchdog Timer' CONFIG_60XX_WDT
+   tristate '  SBC-60XX Watchdog Timer' CONFIG_60XX_WDT
    tristate '  Mixcom Watchdog' CONFIG_MIXCOMWD 
+   tristate '  Intel i810 TCO timer / Watchdog' CONFIG_I810_TCO
    if [ "$CONFIG_FOOTBRIDGE" = "y" ]; then
       tristate '  DC21285 watchdog' CONFIG_21285_WATCHDOG
       if [ "$CONFIG_ARCH_NETWINDER" = "y" ]; then
@@ -143,98 +152,7 @@
    bool 'Tadpole ANA H8 Support'  CONFIG_H8
 fi
 
-mainmenu_option next_comment
-comment 'Video For Linux'
-
-tristate 'Video For Linux' CONFIG_VIDEO_DEV
-if [ "$CONFIG_VIDEO_DEV" != "n" ]; then
-   bool '  V4L information in proc filesystem' CONFIG_VIDEO_PROC_FS Y
-   dep_tristate '  I2C on parallel port' CONFIG_I2C_PARPORT $CONFIG_PARPORT $CONFIG_I2C
-   comment 'Radio Adapters'
-   dep_tristate '  ADS Cadet AM/FM Tuner' CONFIG_RADIO_CADET $CONFIG_VIDEO_DEV
-   dep_tristate '  AIMSlab RadioTrack (aka RadioReveal) support' CONFIG_RADIO_RTRACK $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_RTRACK" = "y" ]; then
-      hex '  RadioTrack i/o port (0x20f or 0x30f)' CONFIG_RADIO_RTRACK_PORT 20f
-   fi
-   dep_tristate '  AIMSlab RadioTrack II support' CONFIG_RADIO_RTRACK2 $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_RTRACK2" = "y" ]; then
-      hex '    RadioTrack II i/o port (0x20c or 0x30c)' CONFIG_RADIO_RTRACK2_PORT 30c
-   fi
-   dep_tristate '  Aztech/Packard Bell Radio' CONFIG_RADIO_AZTECH $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_AZTECH" = "y" ]; then
-      hex '    Aztech/Packard Bell I/O port (0x350 or 0x358)' CONFIG_RADIO_AZTECH_PORT 350
-   fi
-   dep_tristate '  GemTek Radio Card support' CONFIG_RADIO_GEMTEK $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_GEMTEK" = "y" ]; then
-      hex '    GemTek i/o port (0x20c, 0x30c, 0x24c or 0x34c)' CONFIG_RADIO_GEMTEK_PORT 34c
-   fi
-   dep_tristate '  Miro PCM20 Radio' CONFIG_RADIO_MIROPCM20 $CONFIG_VIDEO_DEV
-   dep_tristate '  SF16FMI Radio' CONFIG_RADIO_SF16FMI $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_SF16FMI" = "y" ]; then
-      hex '    SF16FMI I/O port (0x284 or 0x384)' CONFIG_RADIO_SF16FMI_PORT 284
-   fi
-   dep_tristate '  TerraTec ActiveRadio ISA Standalone' CONFIG_RADIO_TERRATEC $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_TERRATEC" = "y" ]; then
-      hex '    Terratec i/o port (normally 0x590)' CONFIG_RADIO_TERRATEC_PORT 590
-   fi
-   dep_tristate '  Trust FM radio card' CONFIG_RADIO_TRUST $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_TRUST" = "y" ]; then
-      hex '    Trust i/o port (usually 0x350 or 0x358)' CONFIG_RADIO_TRUST_PORT 350
-   fi
-   dep_tristate '  Typhoon Radio (a.k.a. EcoRadio)' CONFIG_RADIO_TYPHOON $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_PROC_FS" = "y" ]; then
-      if [ "$CONFIG_RADIO_TYPHOON" != "n" ]; then
-	 bool '    Support for /proc/radio-typhoon' CONFIG_RADIO_TYPHOON_PROC_FS
-      fi
-   fi
-   if [ "$CONFIG_RADIO_TYPHOON" = "y" ]; then
-      hex '  Typhoon I/O port (0x316 or 0x336)' CONFIG_RADIO_TYPHOON_PORT 316
-      int '  Typhoon frequency set when muting the device (kHz)' CONFIG_RADIO_TYPHOON_MUTEFREQ 87500
-   fi
-   dep_tristate '  Zoltrix Radio' CONFIG_RADIO_ZOLTRIX $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_RADIO_ZOLTRIX" = "y" ]; then
-      hex '    ZOLTRIX I/O port (0x20c or 0x30c)' CONFIG_RADIO_ZOLTRIX_PORT 20c
-   fi
-   comment 'Video Adapters'
-   if [ "$CONFIG_I2C_ALGOBIT" = "y" -o "$CONFIG_I2C_ALGOBIT" = "m" ]; then
-      dep_tristate '  BT848 Video For Linux' CONFIG_VIDEO_BT848 $CONFIG_VIDEO_DEV $CONFIG_PCI $CONFIG_I2C_ALGOBIT
-   fi
-   dep_tristate '  Mediavision Pro Movie Studio Video For Linux' CONFIG_VIDEO_PMS $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_ALL_PPC" = "y" ]; then
-      dep_tristate '  PlanB Video-In on PowerMac' CONFIG_VIDEO_PLANB $CONFIG_VIDEO_DEV
-   fi
-   if [ "$CONFIG_PARPORT" != "n" ]; then
-      dep_tristate '  Quickcam BW Video For Linux' CONFIG_VIDEO_BWQCAM $CONFIG_VIDEO_DEV $CONFIG_PARPORT
-      if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-	 dep_tristate '  QuickCam Colour Video For Linux (EXPERIMENTAL)' CONFIG_VIDEO_CQCAM $CONFIG_VIDEO_DEV $CONFIG_PARPORT
-      fi
-   fi
-   dep_tristate '  CPiA Video For Linux' CONFIG_VIDEO_CPIA $CONFIG_VIDEO_DEV
-   if [ "$CONFIG_VIDEO_CPIA" != "n" ]; then
-     if [ "CONFIG_PARPORT_1284" != "n" ]; then
-       dep_tristate '    CPiA Parallel Port Lowlevel Support' CONFIG_VIDEO_CPIA_PP $CONFIG_VIDEO_CPIA $CONFIG_PARPORT
-     fi
-     if [ "$CONFIG_USB" != "n" ]; then
-       dep_tristate '    CPiA USB Lowlevel Support' CONFIG_VIDEO_CPIA_USB $CONFIG_VIDEO_CPIA $CONFIG_USB
-     fi
-   fi
-   dep_tristate '  SAA5249 Teletext processor' CONFIG_VIDEO_SAA5249 $CONFIG_VIDEO_DEV $CONFIG_I2C
-   dep_tristate '  SAB3036 tuner' CONFIG_TUNER_3036 $CONFIG_VIDEO_DEV $CONFIG_I2C
-   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-      if [ "$CONFIG_SGI" = "y" ]; then
-         dep_tristate '  SGI Vino Video For Linux (EXPERIMENTAL)' CONFIG_VIDEO_VINO $CONFIG_VIDEO_DEV $CONFIG_SGI
-      fi
-      dep_tristate '  Stradis 4:2:2 MPEG-2 video driver  (EXPERIMENTAL)' CONFIG_VIDEO_STRADIS $CONFIG_VIDEO_DEV $CONFIG_PCI
-   fi
-   dep_tristate '  Zoran ZR36057/36060 Video For Linux' CONFIG_VIDEO_ZORAN $CONFIG_VIDEO_DEV $CONFIG_PCI
-   dep_tristate '    Include support for Iomega Buz' CONFIG_VIDEO_BUZ $CONFIG_VIDEO_ZORAN
-   dep_tristate '  Zoran ZR36120/36125 Video For Linux' CONFIG_VIDEO_ZR36120 $CONFIG_VIDEO_DEV $CONFIG_PCI $CONFIG_I2C
-fi
-
-endmenu
-
 tristate 'Double Talk PC internal speech card support' CONFIG_DTLK
-
 tristate 'Siemens R3964 line discipline' CONFIG_R3964
 tristate 'Applicom intelligent fieldbus card support' CONFIG_APPLICOM
 
Index: linux/drivers/char/Makefile
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/char/Makefile,v
retrieving revision 1.14
diff -u -r1.14 Makefile
--- linux/drivers/char/Makefile	2000/08/11 00:16:02	1.14
+++ linux/drivers/char/Makefile	2000/08/27 18:32:48
@@ -36,13 +36,9 @@
 # All of the (potential) objects that export symbols.
 # This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
 
-export-objs     :=	vt.o i2c-old.o keyboard.o sysrq.o \
-			misc.o pty.o random.o selection.o serial.o videodev.o \
-			tty_io.o bttv-if.o cpia.o
+export-objs     :=	vt.o keyboard.o sysrq.o misc.o pty.o \
+			random.o selection.o serial.o tty_io.o
 
-list-multi	:=	bttv.o
-bttv-objs	:=	bttv-driver.o bttv-cards.o bttv-if.o
-
 KEYMAP   =defkeymap.o
 CONSOLE  =vt.o
 SERIAL   =serial.o
@@ -57,18 +53,15 @@
 endif
 
 ifeq ($(ARCH),arm)
-# we actually need to be able to select various different keymaps
-# and keyboards dependent on which actual machine we're going to
-# run on.
-  KEYMAP   =
-  KEYBD    =
+  ifneq ($(CONFIG_PC_KEYMAP),y)
+    KEYMAP   =
+  endif
 endif
 
 ifeq ($(ARCH),sh)
-  CONSOLE  =
-  ifeq ($(CONFIG_SH_HP600),y)
-  KEYMAP   = defkeymap.o
-  KEYBD    = scan_keyb.o hp600_keyb.o
+  ifneq ($(CONFIG_SH_HP600),y)
+    CONSOLE  =
+    KEYMAP   =
   endif
 endif
 
@@ -142,44 +135,10 @@
   obj-$(CONFIG_NVRAM) += nvram.o
 endif
 
-obj-$(CONFIG_VIDEO_DEV) += videodev.o
-
 obj-$(CONFIG_21285_WATCHDOG) += wdt285.o
 obj-$(CONFIG_977_WATCHDOG) += wdt977.o
 obj-$(CONFIG_DS1620) += ds1620.o
 obj-$(CONFIG_INTEL_RNG) += i810_rng.o
-
-obj-$(CONFIG_BUS_I2C) += i2c-old.o
-obj-$(CONFIG_VIDEO_BT848) += bttv.o msp3400.o \
-	tda7432.o tda8425.o tda985x.o tda9875.o tea6300.o tea6420.o tuner.o
-obj-$(CONFIG_SOUND_TVMIXER) += tvmixer.o
-
-obj-$(CONFIG_VIDEO_ZR36120) += zoran.o i2c-old.o tuner.o saa7110.o saa7111.o saa7185.o 
-obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o i2c-old.o
-obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o i2c-old.o
-obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
-obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
-obj-$(CONFIG_VIDEO_ZORAN) += buz.o i2c-old.o saa7110.o saa7111.o saa7185.o 
-obj-$(CONFIG_VIDEO_LML33) += bt856.o bt819.o
-obj-$(CONFIG_VIDEO_PMS) += pms.o
-obj-$(CONFIG_VIDEO_PLANB) += planb.o
-obj-$(CONFIG_VIDEO_VINO) += vino.o
-obj-$(CONFIG_VIDEO_STRADIS) += stradis.o
-obj-$(CONFIG_VIDEO_CPIA) += cpia.o
-obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o
-obj-$(CONFIG_VIDEO_CPIA_USB) += cpia_usb.o
-obj-$(CONFIG_RADIO_AZTECH) += radio-aztech.o
-obj-$(CONFIG_RADIO_RTRACK2) += radio-rtrack2.o
-obj-$(CONFIG_RADIO_SF16FMI) += radio-sf16fmi.o
-obj-$(CONFIG_RADIO_CADET) += radio-cadet.o
-obj-$(CONFIG_RADIO_TYPHOON) += radio-typhoon.o
-obj-$(CONFIG_RADIO_TERRATEC) += radio-terratec.o
-obj-$(CONFIG_RADIO_RTRACK) += radio-aimslab.o
-obj-$(CONFIG_RADIO_ZOLTRIX) += radio-zoltrix.o
-obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
-obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o
-obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
-obj-$(CONFIG_TUNER_3036) += tuner-3036.o
 obj-$(CONFIG_QIC02_TAPE) += tpqic02.o
 
 ifeq ($(CONFIG_FTAPE),y)
@@ -227,36 +186,17 @@
   endif
 endif
 
-# Extract lists of the multi-part drivers.
-# The 'int-*' lists are the intermediate files used to build the multi's.
-
-multi-y         := $(filter $(list-multi), $(obj-y))
-multi-m         := $(filter $(list-multi), $(obj-m))
-int-y           := $(sort $(foreach m, $(multi-y), $($(basename $(m))-objs)))
-int-m           := $(sort $(foreach m, $(multi-m), $($(basename $(m))-objs)))
-
 # Files that are both resident and modular: remove from modular.
-
 obj-m           := $(filter-out $(obj-y), $(obj-m))
-int-m           := $(filter-out $(int-y), $(int-m))
 
-# Take multi-part drivers out of obj-y and put components in.
-
-obj-y           := $(filter-out $(list-multi), $(obj-y)) $(int-y)
-
 # Translate to Rules.make lists.
-
 O_OBJS          := $(filter-out $(export-objs), $(obj-y))
 OX_OBJS         := $(filter     $(export-objs), $(obj-y))
 M_OBJS          := $(sort $(filter-out $(export-objs), $(obj-m)))
 MX_OBJS         := $(sort $(filter     $(export-objs), $(obj-m)))
-MI_OBJS		:= $(sort $(filter-out $(export-objs), $(int-m)))
-MIX_OBJS	:= $(sort $(filter     $(export-objs), $(int-m)))
 
 include $(TOPDIR)/Rules.make
 
-fastdep:
-
 conmakehash: conmakehash.c
 	$(HOSTCC) $(HOSTCFLAGS) -o conmakehash conmakehash.c
 
@@ -267,10 +207,3 @@
 
 defkeymap.c: defkeymap.map
 	loadkeys --mktable defkeymap.map > defkeymap.c
-
-zoran.o: zr36120.o zr36120_i2c.o zr36120_mem.o
-	$(LD) $(LD_RFLAG) -r -o $@ zr36120.o zr36120_i2c.o zr36120_mem.o
-
-bttv.o: $(bttv-objs)
-	$(LD) $(LD_RFLAG) -r -o $@ $(bttv-objs)
-
Index: linux/drivers/usb/Config.in
===================================================================
RCS file: /cvsroot/linuxconsole/ruby/linux/drivers/usb/Config.in,v
retrieving revision 1.9
diff -u -r1.9 Config.in
--- linux/drivers/usb/Config.in	2000/07/30 14:42:08	1.9
+++ linux/drivers/usb/Config.in	2000/08/27 18:32:50
@@ -68,7 +68,7 @@
    dep_tristate '  DABUSB driver' CONFIG_USB_DABUSB $CONFIG_USB
    if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
       dep_tristate '  PLUSB Prolific USB-Network driver (EXPERIMENTAL)' CONFIG_USB_PLUSB $CONFIG_USB $CONFIG_NET
-      dep_tristate '  USB ADMtek Pegasus-based device support (EXPERIMENTAL)' CONFIG_USB_PEGASUS $CONFIG_USB $CONFIG_NET
+      dep_tristate '  USB ADMtek Pegasus-based ethernet device support (EXPERIMENTAL)' CONFIG_USB_PEGASUS $CONFIG_USB $CONFIG_NET
       dep_tristate '  USB Diamond Rio500 support (EXPERIMENTAL)' CONFIG_USB_RIO500 $CONFIG_USB
       dep_tristate '  D-Link USB FM radio support (EXPERIMENTAL)' CONFIG_USB_DSBR $CONFIG_USB $CONFIG_VIDEO_DEV
       dep_tristate '  USB Bluetooth support (EXPERIMENTAL)' CONFIG_USB_BLUETOOTH $CONFIG_USB
-- 
Always remember that you are unique.  Just like everyone else.

Re: New VGA console coming

[James S. <jsi...@ac...>]

> >    Now for the next step in the evolution of the console system. Well I
> > made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can 
> > display asian characters. I also discovered some old BIOS calls that might
> > lead to figuring out if double byte fonts could be supported. The BIOS
> > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads
> > to me to believe it might be possible for VGA to support double byte
> > fonts. This of course would mean a rethinking of how the shadow buffer
> > should be done. Any ideas anyone?
> 
> Well, it might be possible, though I never have seen a card that would
> be capable of that. Even the version of Ralf Brown's interrupt list
> doesn't say anything about that.

It is there. Int 10/AH=18h. Their is also a AH=19h (Japanese VIDEO -
DOUBLE-BYTE CHARACTER SET SHIFT). Not much info tho :-( As for the 
text modes (mode 52h) that support 16 bit characters appears to be
actually vga 16 color graphics modes. I still like to know where those
extra fonts are stored. Maybe in regular memory. We do have vgafb which
could be made to support 16 bit characters. Since vgafb is supported on 
any platform that vgacon is this expands the range of languages linux can
support. The only problem is ...

> What might be interesting, though, is using the feature that int 10, ah
> 11, al 3 allows. It can be easily set via registers as well.
> 512-character font could be very useful for Unicode mappings.
>
> Another cute feature possible would be to use the font page in the VGA
> card (be it 256 or 512 characters) as a cache of letter images, and only
> use those that are displayed on screen. This would allow using huge
> fonts (> 512 chars), assuming that one never uses all the letters at
> once. Full Unicode support, for example. 

... how to handle so many fonts. I like the idea of a cache of X amount of
characters. Even for fbcon this would be useful. As for the layout of the
shadow buffer. We really need to reconsider its layout. With the idea of
a font cache how about this. 16 bits is used to represent each character. 
The high 8 bits are a index to different font caches. This allows 256
different font caches. The lower 8 bits acts as a index into the font
cache. Now what to do with the attributes? The idea of having 24 bits to
represent a text charachter botehrs me. I prefere if it was 32 bits. We
have to do alot of shifting bits around to get to work otherwise. 

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: New VGA console coming

[Vojtech P. <vo...@su...>]

On Sat, Aug 26, 2000 at 11:17:56PM -0400, James Simmons wrote:

>    Now for the next step in the evolution of the console system. Well I
> made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can 
> display asian characters. I also discovered some old BIOS calls that might
> lead to figuring out if double byte fonts could be supported. The BIOS
> call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads
> to me to believe it might be possible for VGA to support double byte
> fonts. This of course would mean a rethinking of how the shadow buffer
> should be done. Any ideas anyone?

Well, it might be possible, though I never have seen a card that would
be capable of that. Even the version of Ralf Brown's interrupt list
doesn't say anything about that.

What might be interesting, though, is using the feature that int 10, ah
11, al 3 allows. It can be easily set via registers as well.
512-character font could be very useful for Unicode mappings.

Another cute feature possible would be to use the font page in the VGA
card (be it 256 or 512 characters) as a cache of letter images, and only
use those that are displayed on screen. This would allow using huge
fonts (> 512 chars), assuming that one never uses all the letters at
once. Full Unicode support, for example. 

-- 
Vojtech Pavlik
SuSE Labs

CVS updates/VGA mode setting

[James S. <jsi...@ac...>]

The CVS has been brought into sync with test7. Our CVS is still in the
ruby style verse what is in the current linus tree. It would be a pain to
re order everything and as Vojtech pointed out its to early to judge what
will happen. It will be settled when 2.5.X comes out.

The second thing which I forgot to mention. I also am going to be working
on getting vgacon to set the mode independent of using anything like the
BIOS. This will allow more portablity and make it more multihead friendly. 
Thsi will also allow the ability to move between different console drivers
like fbcon and vgacon. With the current tree you can only go from vgacon
to fbcon. I plan to make the reverse true. This will also allow recovery
when userland apps don't reset the hardware properly. Now vagcon can reset
the hardware it's self. 

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

New VGA console coming

[James S. <jsi...@ac...>]

Hi!

   It's been some time since I have posted here with what I'm doing. At
first I was playing with the idea of a universal VC switching function.
This lead to my discovery of how vgacon and screenbuf inter act. TO
discribe what my goals are I have to first describe what I understand of
the console system. If I have a misconcept tell me I'm wrong.

   In the current console system (ruby) each struct vc_data represents
each vitrual console. Only one is active at a time on each VT. Now each 
struct vc_data has a vc_screenbuf which is a shadow buffer where text
values are stored. This allows text to be written to non visible consoles.
Only for the visible VC is the text inside of show buffer is actually
drawn with functions defined in struct consw. 
   This is true for all drivers except vgacon. Why? Because the console
system was originally designed around the VGA text hardware mode. Because
of this the shadow buffer layout matches the VGA text mode layout. Now to
describe this shadow buffer. The shadow buffer is a buffer that is x
columns wide and y rows high. For normal VGA text mode this is usually
80x25.

 80 columns wide

-----------------
|		|
|		|  25 rows. 
|		|  
|		|
-----------------

So the shadow buffer is (80x25 * 2) wide. The reason for the 2 is each
component is 16 bits wide. The high 8 bits represent the text attributes.
These are blinking, underline etc. The low 8 bits represent the text
value, usually a acsii character. For vgacon the shadow buffer of the
visible VC points directly to the VGA text buffer. Now VGA hardware has
built in font images. So a mapping happens from the value in buffer to the
font images in the cards memory.
   
   Now for the next step in the evolution of the console system. Well I
made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can 
display asian characters. I also discovered some old BIOS calls that might
lead to figuring out if double byte fonts could be supported. The BIOS
call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads
to me to believe it might be possible for VGA to support double byte
fonts. This of course would mean a rethinking of how the shadow buffer
should be done. Any ideas anyone?


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: What do we do (test7)?

[James S. <jsi...@ac...>]

> On Sat, Aug 26, 2000 at 09:28:37AM -0400, James Simmons wrote:
> 
> > Okay. I think we should leave things as they are. We will see what happens
> > when 2.5.X comes around are where things go. As long as the input suite
> > stays I'm happy. For those that didn't follow the thread linus considered
> > removing the input system :-( 
> 
> I don't think he was very serious about that, though.

Thank goodness. By the way his obsession with X windows, especially
Xfree86 scares me.