Re: board with broken vga ...

Re: board with broken vga ...

[Petr Vandrovec]

On 18 Jul 02 at 9:51, Sven Luther wrote:
> 
> Ok, that said, i suppose ours are the only boards with such problems,
> but since there is so much taken out of the drivers in your new setup
> and put in a common place, would it not solve this problem if there were
> an additional function which driver could provide (or fill in NULL if
> there was no proble), for retrieving this data, which fbcon can write
> back later on ?

Unfortunately there is no such hook. Fortunately call sequence is:

your drivers's init
   --> look and init devices
       --> call register_framebuffer
           --> VGACON reads contents of VGA buffer
           --> call to fbdev setvar
           --> upper layer restores screen
...
With matroxfb I moved all initialization which changes framebuffer layout
to the setvar call, and so VGACON finds hardware in VGA, and not MMIO,
state.

You can look at drivers/char/console.c: take_over_console calls
save_screen, which in turn calls con_save_screen method of vgacon.
So you can try directly overwritting vgacon's savescreen procedure

extern struct consw vga_con;
vga_con.con_save_screen = myOwnSaveScreen;

if you find that your fbdev is primary VGA device. Of course it is
not tested, and I cannot recommend doing that...
                                                    Petr
                                                    


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: board with broken vga ...

[Sven Luther]

On Thu, Jul 18, 2002 at 11:42:57AM +0200, Petr Vandrovec wrote:
> On 18 Jul 02 at 9:51, Sven Luther wrote:
> > 
> > Ok, that said, i suppose ours are the only boards with such problems,
> > but since there is so much taken out of the drivers in your new setup
> > and put in a common place, would it not solve this problem if there were
> > an additional function which driver could provide (or fill in NULL if
> > there was no proble), for retrieving this data, which fbcon can write
> > back later on ?
> 
> Unfortunately there is no such hook. Fortunately call sequence is:

Yes, i know, but would such a hook be a good addition for the new API or
something ? 

Altough, it is true that maybe only pm2fb and pm3fb will make use of it,
it would be cleaner than patching vgacon code for it.

> your drivers's init
>    --> look and init devices
>        --> call register_framebuffer
>            --> VGACON reads contents of VGA buffer

So vgacon is responsible for (wrongly) reading the text data from the
board.

>            --> call to fbdev setvar
>            --> upper layer restores screen
> ...
> With matroxfb I moved all initialization which changes framebuffer layout
> to the setvar call, and so VGACON finds hardware in VGA, and not MMIO,
> state.

Mmm, that may be an idea, provided the normal VGA stuff is not broken.

> You can look at drivers/char/console.c: take_over_console calls
> save_screen, which in turn calls con_save_screen method of vgacon.
> So you can try directly overwritting vgacon's savescreen procedure
> 
> extern struct consw vga_con;
> vga_con.con_save_screen = myOwnSaveScreen;
> 
> if you find that your fbdev is primary VGA device. Of course it is
> not tested, and I cannot recommend doing that...

Ok, i will look at it, thanks.

Friendly,

Sven Luther
>                                                     Petr
>                                                     


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: board with broken vga ...

[Sven Luther]

On Thu, Jul 18, 2002 at 01:36:42PM +0200, Sven Luther wrote:
> On Thu, Jul 18, 2002 at 11:42:57AM +0200, Petr Vandrovec wrote:
> > On 18 Jul 02 at 9:51, Sven Luther wrote:
> > > 
> > > Ok, that said, i suppose ours are the only boards with such problems,
> > > but since there is so much taken out of the drivers in your new setup
> > > and put in a common place, would it not solve this problem if there were
> > > an additional function which driver could provide (or fill in NULL if
> > > there was no proble), for retrieving this data, which fbcon can write
> > > back later on ?
> > 
> > Unfortunately there is no such hook. Fortunately call sequence is:
> 
> Yes, i know, but would such a hook be a good addition for the new API or
> something ? 
> 
> Altough, it is true that maybe only pm2fb and pm3fb will make use of it,
> it would be cleaner than patching vgacon code for it.
> 
> > your drivers's init
> >    --> look and init devices
> >        --> call register_framebuffer
> >            --> VGACON reads contents of VGA buffer
> 
> So vgacon is responsible for (wrongly) reading the text data from the
> board.
> 
> >            --> call to fbdev setvar
> >            --> upper layer restores screen
> > ...
> > With matroxfb I moved all initialization which changes framebuffer layout
> > to the setvar call, and so VGACON finds hardware in VGA, and not MMIO,
> > state.
> 
> Mmm, that may be an idea, provided the normal VGA stuff is not broken.
> 
> > You can look at drivers/char/console.c: take_over_console calls
> > save_screen, which in turn calls con_save_screen method of vgacon.
> > So you can try directly overwritting vgacon's savescreen procedure
> > 
> > extern struct consw vga_con;
> > vga_con.con_save_screen = myOwnSaveScreen;

I tried this, but without success, well it worked, but the corruption is
still there.

when i read ->vc_origin, i can see somewhat of the stuff i have in my
scren after the switch.

when i read the framebuffer directly, i get the console as it should be
(at every 8 bytes, so i guess the attributes are in some of the other 7
bytes, either just behind or before it, or at an 4 bytes offset).

I tried writing plain 'X' chars to the ->vc_screenbuf, but nothing
happens (but the stuff i read directly has now 'X's in background as
below :

880Linux version 2.5.25 (luther@iliana) (gcc version 2.95.4 20011002
(Debian prerel
960ease)) #14 Thu Jul 18 17:37:48 CEST 2002XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1040Video mode to be used for restore is f00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1120BIOS-provided physical RAM map:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1200 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)XXXXXXXXXXXXXXXXXXXXXXXX
1280 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)XXXXXXXXXXXXXXXXXXXXXX
1360 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)XXXXXXXXXXXXXXXXXXXXXX

What seems strange is that i read these stuff before calling
register_framebuffer, so how can the 'X' i write there afterward appear
?

Clearly something strange is going on, i will investigate more.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: board with broken vga ...

[Sven LUTHER]

Petr wrote :
> your drivers's init
>    --> look and init devices
>        --> call register_framebuffer
>            --> VGACON reads contents of VGA buffer
>            --> call to fbdev setvar
>            --> upper layer restores screen
> ...

Mmm, i did manage to override the vga save_screen function, and copy the
good values into vc_sceenbuf, but to no avail.

What frustrates me is that i cannot find any reference to some piece of
code using the data in vc_sceenbuf to write to the screen again.

How exactly does the upper layer restore the screen ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

board with broken vga ...

[Sven Luther]

Hello, ...

i am looking again at pm3fb (still old style one though).

Permedia3 (and probably permedia2 also) has a problem with accessing vga
stuff in mmio mode, which makes it not work correctly when the text from
the vga console mode is copied over to the fbcon at the switch.

I have the understanding that you moved this stuff over to some other
place and not the pm3fb driver itself (but where ?)

I now know how to get this data by looking at the framebuffer directly
(it is found starting at framebuffer addr + 0 in 8 byte steps.), but
need to know how i can hook it in, to write it back.

Also, the size of this text is somewhat of a mistery for me still.

Ok, that said, i suppose ours are the only boards with such problems,
but since there is so much taken out of the drivers in your new setup
and put in a common place, would it not solve this problem if there were
an additional function which driver could provide (or fill in NULL if
there was no proble), for retrieving this data, which fbcon can write
back later on ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf