linuxconsole-dev

Re: event mixer patch

[Paul M. <pm...@mv...>]

On Tue, Jun 19, 2001 at 02:15:22PM -0700, James Simmons wrote:
> > The patch is simply to clean up some of the input code and to avoid code
> > duplication and a few potential oopses from occasionally dereferencing a
> > NULL pointer.
> 
> Is this a seperate patch or the patch from Charles? I looked at his patch
> and it has only one line change in input.c. Very nice patch. After I'm
> done with power management today I will incorporate it. Probable some
> time tomorrow unless Vojtech has any objections.
> 
Seperate patch, it was attached to my reply to Charles' original message.
I've attached it to this one as well. I'll commit it if no one has any
problems with it.

Regards,

-- 
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: Role of close() in struct input_dev

[Johann D. <jo...@Do...>]

On Tue, 19 Jun 2001, James Simmons wrote:

> 
> > There are parts of evdev functions called by userland, and other parts
> > called by other modules. Namely, evdev_disconnect can be called by serio,
> > for example.
> > The problem is still there: I would expect
> > input_open_device/input_close_devise to be called at least the same
> > number of times (perhaps we should even take care of the order).
> 
> Both would be called the same number of time. Well I hope. The order is
> what matters. 

After further checks, yes they actually are called the same number of
times.
In fact, I realised the driver doesn't really know when a process does an
open(). Indeed, input_open_device is called only when the first process
opens the device, and input_close_device when all processes closed it.
I would however need a function to be called every time a process accesses
an i-force device.
Two solutions:

- I modify the existing input_{open,close}_device
Frankly, I don't really like the fact that evdev can be kfreed both by
evdev_disconnect and evdev_connect. Furthermore, the choice is done after
the value of evdev->exist, whose access is not protected (possible bug if
the last process releases the device while the device is being
disconnected, on a smp machine (weird case, though))

- I add new callbacks to input_dev
I need to make modifications to this struct, and having two different kind
of open functions may be confusing. If driver writers need to make a
distinction between the first open(), and subsequent open(), they can
handle it themselves.



Anyway, it seems we have to check evdev->exist before doing anything in
evdev_{ioctl,read,write...}, I guess this is what caused the oops I got.


-- 
Johann Deneux
CS student at DoCS (www.docs.uu.se/~johannd) and
ESIL (www.esil.univ-mrs.fr/~jdeneux)

Re: event mixer patch

[Franz S. <Fra...@la...>]

On Tuesday 19 June 2001 23:15, James Simmons wrote:
> > I meant a more unified solution as it applied to the input code.
>
> Okay. Misunderstood you.
>
> > The patch is simply to clean up some of the input code and to avoid code
> > duplication and a few potential oopses from occasionally dereferencing a
> > NULL pointer.
>
> Is this a seperate patch or the patch from Charles? I looked at his patch
> and it has only one line change in input.c. Very nice patch. After I'm
> done with power management today I will incorporate it. Probable some
> time tomorrow unless Vojtech has any objections.

Last time I asked Vojtech wasn't very pleased of that idea, eg. it doesn't 
make  much sense to mix in EV_ABS devices.

Maybe it should be a separate module providing a whole class of event mix 
devices, with all EV_KEY and EV_REL mixed on /dev/eventmix0 by default. Then 
there could be ioctl's to attach and detach single event devices onto the 
mixer devices.

Franz.

power management

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

So far for power management I have:

Placed a pm_dev inside input_dev.

If the input_dev has a struct pm_dev we do the following.

Every time input_open is called pm_access is called.

When input_close is called and handle->open==0 I call pm_idle_dev

For input_unregister_device I call pm_unregister(dev->pm_dev);

I find pm_register_device too driver specific to make generic. 
The next problem is power management for that particular device via a
key/button. I like to power the device off/on and control the level of
power going to the device. For example the touchscreen I'm working on. It
would be nice to dim/brighten the frontlight. The question is how to
implement this fine grain control.

P.S
   serio->write can send only one char at a time? 

Re: event mixer patch

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

> I meant a more unified solution as it applied to the input code. 

Okay. Misunderstood you.

> The patch is simply to clean up some of the input code and to avoid code
> duplication and a few potential oopses from occasionally dereferencing a
> NULL pointer.

Is this a seperate patch or the patch from Charles? I looked at his patch
and it has only one line change in input.c. Very nice patch. After I'm
done with power management today I will incorporate it. Probable some
time tomorrow unless Vojtech has any objections.

@@ -354,7 +354,8 @@
        while (*handlerptr && (*handlerptr != handler))
                handlerptr = &((*handlerptr)->next);

-       *handlerptr = (*handlerptr)->next;
+       if(*handlerptr)
+               *handlerptr = (*handlerptr)->next;

Re: Role of close() in struct input_dev

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

> There are parts of evdev functions called by userland, and other parts
> called by other modules. Namely, evdev_disconnect can be called by serio,
> for example.
> The problem is still there: I would expect
> input_open_device/input_close_devise to be called at least the same
> number of times (perhaps we should even take care of the order).

Both would be called the same number of time. Well I hope. The order is
what matters. 

> > P.S
[snip]...
> > 
> Ok, I will play with the files and try to figure out everything
> locally. We should not have sync problem, but I will wait for you to be
> finished before commiting anything.

I have to do some testing on the ipaq first. I pretty much hammered the
power down each device. Will send a seperate email on this:

Re: Role of close() in struct input_dev

[Johann D. <jo...@Do...>]

On Tue, 19 Jun 2001, James Simmons wrote:

> 
> > Now the question is: What is the role of input_dev::close/open ?
> > Are they meant as "init/deinit the device" or "establish/break connection
> > with processes" (or a mix of both) ?
> 
> If you look at input.c connect and disconnect are used by input_register
> and input_unregister which are called when you insmod the device or at
> boot time. So they are used to setup the hardware and the data structs for
> the device. Now open and close are called input_open_device and
> input_close_device. Now if look at what calls input_[opne/close]_device
> they are all some kind of userland interface i.e evdev, mousedev, joydev.c
> etc. 

There are parts of evdev functions called by userland, and other parts
called by other modules. Namely, evdev_disconnect can be called by serio,
for example.
The problem is still there: I would expect
input_open_device/input_close_devise to be called at least the same
number of times (perhaps we should even take care of the order).

> 
> P.S
> 
>    Lets coordinate our work. I'm working on power management right now
> which also changes things like input.c. I have pretty much figured out pm
> handling per device. The problem is general powering down a device. How to
> handle things like a power power that suspends a PDA. This is much
> trickier.
> 
Ok, I will play with the files and try to figure out everything
locally. We should not have sync problem, but I will wait for you to be
finished before commiting anything.

-- 
Johann Deneux
CS student at DoCS (www.docs.uu.se/~johannd) and
ESIL (www.esil.univ-mrs.fr/~jdeneux)

Re: Role of close() in struct input_dev

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

> Now the question is: What is the role of input_dev::close/open ?
> Are they meant as "init/deinit the device" or "establish/break connection
> with processes" (or a mix of both) ?

If you look at input.c connect and disconnect are used by input_register
and input_unregister which are called when you insmod the device or at
boot time. So they are used to setup the hardware and the data structs for
the device. Now open and close are called input_open_device and
input_close_device. Now if look at what calls input_[opne/close]_device
they are all some kind of userland interface i.e evdev, mousedev, joydev.c
etc. 

P.S

   Lets coordinate our work. I'm working on power management right now
which also changes things like input.c. I have pretty much figured out pm
handling per device. The problem is general powering down a device. How to
handle things like a power power that suspends a PDA. This is much
trickier.

Re: event mixer patch

[Paul M. <pm...@mv...>]

On Tue, Jun 19, 2001 at 10:33:17AM -0700, James Simmons wrote:
> > This brings up a few other potential issues in various other portions of
> > the code. This current approach is far too ugly, there are all sorts of
> > opportunities where it could be dereferencing NULL, etc.
> >=20
> > A more general solution for this kind of finding/removal of nodes from
> > the linked list would likely be a better solution.
> >=20
> > What does everyone think about something like the attached patch as a
> > more unified solution?
>=20
> Their is linux/include/linux/list.h which is a generic interface for
> double link list. From what I see their is no single link list
> implementation.

I meant a more unified solution as it applied to the input code. It would
be a nuisance to rewrite all the list handling in the input code to utilize
a doubly linked list, and I don't think there's quite enough demand to
bother writing a single linked list implementation.

The patch is simply to clean up some of the input code and to avoid code
duplication and a few potential oopses from occasionally dereferencing a
NULL pointer.

On top of that, the patch is pretty much isolated to drivers/input/input.c
and suits its purpose fairly well IMO.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Role of close() in struct input_dev

[Johann D. <jo...@Do...>]

Hi !

I am trying to clean up my addition about multiple open-with-write-access.
My first idea was to use a flag, only_one_writer in struct evdev, and then
perform the necessay checks in evdev_open and evdev_release.

Vojtech suggested that we add a parameter to input_dev::open and pass
that parameter to device drivers and let them decide. This would indeed
allow for more flexibility.
I thought that input_dev::close should be modified the same way.

I tried to implement this, and while doing so, I noticed that it could be
that input_dev::open and input_dev::close are not called the same number
of times. This may or may not be a problem, I don't know.

Here is a sample scenario:
1. Application 1 opens /dev/input/event0
2. Application 2 opens /dev/input/event0 (nothing forbids that)
3. evdev_disconnect is called (usb device is unplugged, input_attach is
kiled...)

Steps 1 and 2 call input_dev::open, step 3 calls input_dev::close.

Now the question is: What is the role of input_dev::close/open ?
Are they meant as "init/deinit the device" or "establish/break connection
with processes" (or a mix of both) ?

I would vote for the second possibility.

By the way, if you add a step 4 to my scenario:
4. Application 1 or 2 writes to /dev/input/event0
then the application segfaults, and dmesg tells me someone tried to
dereference a NULL pointer.

-- 
Johann Deneux
CS student at DoCS (www.docs.uu.se/~johannd) and
ESIL (www.esil.univ-mrs.fr/~jdeneux)

Re: event mixer patch

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

> This brings up a few other potential issues in various other portions of
> the code. This current approach is far too ugly, there are all sorts of
> opportunities where it could be dereferencing NULL, etc.
> 
> A more general solution for this kind of finding/removal of nodes from
> the linked list would likely be a better solution.
> 
> What does everyone think about something like the attached patch as a
> more unified solution?

Their is linux/include/linux/list.h which is a generic interface for
double link list. From what I see their is no single link list
implementation.

Re: event mixer patch

[Paul M. <pm...@mv...>]

On Mon, Jun 18, 2001 at 10:09:56PM -0700, Charles Duffy wrote:
> @@ -354,7 +354,8 @@
>  	while (*handlerptr && (*handlerptr != handler))
>  		handlerptr = &((*handlerptr)->next);
>  
> -	*handlerptr = (*handlerptr)->next;
> +	if(*handlerptr)
> +		*handlerptr = (*handlerptr)->next;
>  
>  /*
>   * Remove minors.

This brings up a few other potential issues in various other portions of
the code. This current approach is far too ugly, there are all sorts of
opportunities where it could be dereferencing NULL, etc.

A more general solution for this kind of finding/removal of nodes from
the linked list would likely be a better solution.

What does everyone think about something like the attached patch as a
more unified solution?

Regards,

-- 
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

event mixer patch

[Charles D. <cd...@mv...>]

The attached patch creates a mixer device for the event interface, as
already exists for mice; indeed, it borrows (very) heavily from the
existing mousedev driver. create the device with "mknod events c 13
95". This patch also addresses an (unrelated) oops which turned up in
testing, though there's no promise that it fixes more than it induces.

Enjoy!

Re: mixer devices for keyboard and/or event interfaces

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

> If I added mixer devices for keyboard and (more usefully) event
> interfaces to the input core, would the patch be accepted? If so, what
> minor numbers should I use?

I have to say I would find this useful as well. It would be nice to have a
multiplex event device. As for the keyboard I'm not so hot for that. GO
ahead and post it. 

mixer devices for keyboard and/or event interfaces

[Charles D. <cd...@mv...>]

Howdy.

If I added mixer devices for keyboard and (more usefully) event
interfaces to the input core, would the patch be accepted? If so, what
minor numbers should I use?

I'm altering a few legacy applications (one of which, being intended
for embedded applications, has little by way of a configuration
interface) to use the event interface.  Having a single file handler
to connect would make things far easier (removing issues such as
tracking changing minor numbers, accepting input from devices
connected during runtime, etc).

Re: Missing key in sunkbd.c

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

Fix added :-) Thank you.

On Sat, 16 Jun 2001, Chris wrote:

> Hi,
>     My apologies if this is old news. While trying to get my key settings
> sorted out, I noticed that the \ key on my Type 4 wasn't doing anything. 
> Looking at sunkbd.c, the entry in sunkbd_keycode corresponding to the 
> \ key contained 0 (the last line in the array, first zero from the right).
> Changing this to 86 allows the use of the \ key. ie: The last line of the
> sunkbd_keycode array should read:
> 
>  79, 80, 81, 0, 0, 0,138, 58,125, 57,126,109, 86, 78 
>  
> Chris
> -- 
> New sig in the works
> Explorer 2260, Designer and Coder
> http://www.starforge.co.uk
> --     
> In case of atomic attack, the federal ruling against prayer in schools
> will be temporarily canceled.
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

Missing key in sunkbd.c

[Chris <ch...@st...>]

Hi,
    My apologies if this is old news. While trying to get my key settings
sorted out, I noticed that the \ key on my Type 4 wasn't doing anything. 
Looking at sunkbd.c, the entry in sunkbd_keycode corresponding to the 
\ key contained 0 (the last line in the array, first zero from the right).
Changing this to 86 allows the use of the \ key. ie: The last line of the
sunkbd_keycode array should read:

 79, 80, 81, 0, 0, 0,138, 58,125, 57,126,109, 86, 78 
 
Chris
-- 
New sig in the works
Explorer 2260, Designer and Coder
http://www.starforge.co.uk
--     
In case of atomic attack, the federal ruling against prayer in schools
will be temporarily canceled.

Re: Patching, video and input

[Chris <ch...@st...>]

#14-Jun-01# Message from *James Simmons*:
Hi James,

> Yes. You don't need to apply the LCP patches to get your sun keyboard
> working. What you do need is in the standard tree:

> Build everything and then build your sunkbd.o driver.

> Then run inputattach which is in our ruby/utils directory.

It all seems to work great, thanks.

> If you need anything else just post to the list.

Well I'd like to say thanks to you and everyone else involved in developing
this code, it's greatly appreciated!

Chris
-- 
New sig in the works
Explorer 2260, Designer and Coder
http://www.starforge.co.uk
--     
God made machine language; all the rest is the work of man.

Re: [Linux-fbdev-devel] 2.4 official API ?

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

> Disclaimer: I didn't do any Ruby driver yet. Atyfb is in my (long) todo bucket.
> 
> I _think_ you can nicely encapsulate a 2.5 style driver using a 2.4
> compatibility layer. Just add some stubs that take care of get_{var,fix}() and
> of the extra con argument.

Pretty much. The approach I toke was to write a fbcon-accel.c file much
like fbcon-cfbX and friends. I have it at home. It had one bug in it
which I need to fix. Since people are really interested in this wrapper I
will work on it this weekend along with docs. 

P.S
   One note to make. The only big difference between 2.4.X with the wrapper 
and ruby will be the ablilty to use DMA. The ruby tree can support cards
in DMA/irq mode whereas in 2.4.X you can't. This is due to the console_lock 
which Andrew Morton and I have rewritten to make possible DMA. Using DMA
will mean certain drivers (matrox and aty128) could be really difference
between ruby and 2.4.X even with the wrapper. 

Re: [Linux-fbdev-devel] 2.4 official API ?

[Geert U. <ge...@li...>]

On Fri, 15 Jun 2001, Ghozlane Toumi wrote:
> So the question is how do i support 2.2/2.4 *and* the upcomming 2.5 API
> without maintainig 3 separate sources : i have to work on the internals of
> the driver,
> and i don't feel like updating 3 files every time ...
> 
> any suggestions ?
> how do you guys cope with that ?

Disclaimer: I didn't do any Ruby driver yet. Atyfb is in my (long) todo bucket.

I _think_ you can nicely encapsulate a 2.5 style driver using a 2.4
compatibility layer. Just add some stubs that take care of get_{var,fix}() and
of the extra con argument.

Since these stubs have to be the same for each driver, what we need is some
include file that provides the compatibility layer, and some additional #ifdefs
I guess, or clever macros.

Is this correct, James?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] 2.4 official API ?

[Ghozlane T. <gt...@pr...>]

----- Original Message -----
From: "James Simmons" <jsi...@tr...>
Subject: Re: [Linux-fbdev-devel] 2.4 official API ?


> It looks like to have to update FB-Driver-HOWTO.

yep .. may i suggest a chapter on the changes between 2.2. and 2.4 ,
and between 2.4 and the upcomming 2.5 API ?

> > is "vfb" up to date, and a good sample of what should be done ? or is it
> > skelettonfb ?
> Both should be updated. I can send a patch which also I hope encourages
> people to migrate to the new api. I like to thank Russell King for moving
> over the arm fbdev drivers to the new api. It makes my life easier :->

I'm for sure interested .

I'm trying to bet back to work on my fb driver (voodoo1 and now voodoo2
officialy almost supported) after letting it sleep for way too long .

I'm having a hard time trying to merge the cleanups/fixes added in
the ruby tree and keeping 2.2/2.4 compatibility ...

So the question is how do i support 2.2/2.4 *and* the upcomming 2.5 API
without maintainig 3 separate sources : i have to work on the internals of
the driver,
and i don't feel like updating 3 files every time ...

any suggestions ?
how do you guys cope with that ?

thanks,
ghoz

Re: [Linux-fbdev-devel] Supporting various depth

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

On 14 Jun 01 at 13:34, James Simmons wrote:
> > On Matrox it is almost same, only constant differs. There are defined 
> > FB_AUX_TEXT_MGA_STEP8 and FB_AUX_TEXT_MGA_STEP16. Millennium1 and
> > G-series use STEP16, Mystique and MillenniumII use STEP8 ... nv3 driver
> > should use STEP8 - maybe after creating FB_AUX_TEXT_STEP8 and
> > obsoleting *_MGA_* values.
> 
> Yipes. What is in that extra space? 8 bytes for one cahracter? I rather
> keep the text modes and the fbdev modes seperate. I like to think of
> /dev/vcsa as for text modes where /dev/fb is the device for graphics
> modes. So I like to see a api developed for text modes. 

There is no discussion that /dev/vcsa interface should contain
<character,attribute> pairs and nothing else. But /dev/fb* in text
mode does not (and cannot) match /dev/vcsa layout, and apps may have
legitimate need for accessing framebuffer directly even in text mode
(although I cannot invent reason directly).

These unused bytes come from simple thing: VGA videoram is organized in
4 planes, and when you are in text mode, even-odd addressing is enabled
so memory looks like:

              0         4         8       12           <- framebuffer offset
plane 0     char0     unused    char1    unused
plane 1     attr0     unused    attr1    unused
plane 2     font0     font1     font2    font3
plane 3     unused    unused    unused   unused

(where font are font data as programmed to VGA) while 
through VGA interface you see:

            char0     attr0      char1    attr1
            
because of address bit A0 does not select bit A2 of memory address, but
instead connects to videoram's A0.

Just some background: in 16color graphics modes CPU bits
A0 -> A15 are connected to VRAM A2 -> A17 and A0,A1 are derived
from GDC's read-plane-select for read and from SEQ's write-plane-enable
for write (for write it is bitmap, for read just one plane is read
unless GDC is in read mode 1).

Nobody prevents you using same mode for text, but in such case interface
at B8000 is not compatible with VGA videomemory layout as remembered
by DOS gurus and as presented in /dev/vcsa (but you can use 128KB
A0000 window and write character at 0xAXXXX and attribute at 0xBXXXX).
If you'll use this layout, framebuffer will look:

char0 attr0 font0 unused
char1 attr1 font1 unused
char2 attr2 font2 unused
...

And you can also program VGA into dword fetch mode, in which memory
layout looks:

  0        4        8        12      16        20      24
char0    unused   unused   unused   char1    unused   unused
attr0    unused   unused   unused   attr1    unused   unused
font0    font1    font2    font3    font4    font5    font6
unused   unused   unused   unused   unused   unused   unused

Millennium1 uses this mode because of reads from framebuffer
returns random data for offsets 4-15 due to bug in their prefetch
circuity (and as stated in manual: when chip is in VGA mode, effect
of accesses through framebuffer is undefined).

G-series instead implement VGA memory not as 4-planes, but as 8-planes
videoram, so standard layout looks:

  0        8       16        24
char0    unused   char1    unused
attr0    unused   attr1    unused
font0    font1    font2    font3
unused   unused   unused   unused
unused   unused   unused   unused
unused   unused   unused   unused
unused   unused   unused   unused
unused   unused   unused   unused

Except for location of font data (they are at 2+X*8 and not at 2+X*4)
it is same as mode I used for Millennium1, and nobody should program
font through /dev/fb*, so I reused same FB_TEXT_AUX value.
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

Re: [Linux-fbdev-devel] Supporting various depth

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

> > In vga: 
> > char[n] is at mem[2n]
> > attribute[n] is at mem[2n+1]
> > 
> > In nv3, linear aperture:
> > char[n] is at mem[8n]
> > attribute[n] is at mem[8n+1]
> 
> On Matrox it is almost same, only constant differs. There are defined 
> FB_AUX_TEXT_MGA_STEP8 and FB_AUX_TEXT_MGA_STEP16. Millennium1 and
> G-series use STEP16, Mystique and MillenniumII use STEP8 ... nv3 driver
> should use STEP8 - maybe after creating FB_AUX_TEXT_STEP8 and
> obsoleting *_MGA_* values.

Yipes. What is in that extra space? 8 bytes for one cahracter? I rather
keep the text modes and the fbdev modes seperate. I like to think of
/dev/vcsa as for text modes where /dev/fb is the device for graphics
modes. So I like to see a api developed for text modes. 

Re: [Linux-fbdev-devel] Supporting various depth

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

On 14 Jun 01 at 21:51, Matan Ziv-Av wrote:
> On Thu, 14 Jun 2001, James Simmons wrote:
> > So basically I need a vga_ops struct that defines functions to access the
> > vga_region. Have any ideas what is needed? How is the linear aperture
> > arranged differently?
> 
> In vga: 
> char[n] is at mem[2n]
> attribute[n] is at mem[2n+1]
> 
> In nv3, linear aperture:
> char[n] is at mem[8n]
> attribute[n] is at mem[8n+1]

On Matrox it is almost same, only constant differs. There are defined 
FB_AUX_TEXT_MGA_STEP8 and FB_AUX_TEXT_MGA_STEP16. Millennium1 and
G-series use STEP16, Mystique and MillenniumII use STEP8 ... nv3 driver
should use STEP8 - maybe after creating FB_AUX_TEXT_STEP8 and
obsoleting *_MGA_* values.
                                        Petr Vandrovec
                                        van...@vc...
                                        

Re: [Linux-fbdev-devel] Supporting various depth

[Matan Ziv-Av <ma...@sv...>]

On Thu, 14 Jun 2001, James Simmons wrote:

> 
> > This won't exactly work - there are some ways to access the vga
> > registers - io (might be remapped from 0x3c0-03df to other address),
> > memory mapped (at any address) or other (nvidia uses other). Also the
> > memory in the linear aperture is organized differently (at least on the
> > nvidia) then the memory at 0xa0000-0xc0000. The solution is probably for
> > the chipset drivers to supply functions (incrtc, outcrtc, etc.)
> 
> So basically I need a vga_ops struct that defines functions to access the
> vga_region. Have any ideas what is needed? How is the linear aperture
> arranged differently?

In vga: 
char[n] is at mem[2n]
attribute[n] is at mem[2n+1]

In nv3, linear aperture:
char[n] is at mem[8n]
attribute[n] is at mem[8n+1]

In other cards it is different from both, but I don't remember the
details.


-- 
Matan Ziv-Av.                         ma...@sv...