linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Jon S. <jon...@ya...>]

--- Antonino Daplas <ad...@po...> wrote:
> 1.  scan for pci devices looking for the vga
> controller type

BIOS provide this via INT for find-pci-device-by-class
= 3

> 2.  if 1 is found other than the primary, disable
> the current controller

Must disable VGA ports. ROM should already be
disabled. The reset program I sent you had the code
for doing the disable properly. You need to poke some
output ports.

No need to diable primary ROM it is not enabled. C000
is a copy of it.

> 3.  write to PCI config space of secondary
> controller the address you
> want it to appear (ie C000:0000).  Can I use other
> addresses?

The ROM will need to appear in an address space hole.
Look in your BIOS for where it is leaving a hole in
the 1MB. Map the VBIOS into the hole and then copy it
to C000. The PC has RAM mapped to C000 so you can't
map the ROM there. 

I believe there is a standard place for this hole
probably E000 or A000 but I would need to reboot to
look.

> 4. enable the controller
> 
> 5. far call c000:0003

This will set up INTs to work on secondary controller.

Now call INT to get EDID data and stick it somewhere
FB can find it.

> 6. disable the controller
> 
> 7. repeat

8) Move the default one back and copy it's ROM back.

You will also need to fix up the INT 10 vectors to
point to the correct entry points for the primary ROM.
The reset code did this too.

> 
> Besides the finer points, did I miss anything
> obvious?
> 
> Tony 
> 


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Antonino D. <ad...@po...>]

On Thu, 2003-03-13 at 02:16, Jon Smirl wrote:
> --- Antonino Daplas <ad...@po...> wrote:
> > Unless I missed some imported BIOS calls or other
> > methods to do this or
> > something similar in real-mode...
> 
> You missed something. The address of the VBIOS ROM can
> be controlled by writing to the PCI config space. You
> can make the ROM appear anywhere you want it to.
> 
> This happens even for the boot video device. 
> Somewhere very early in the boot the system BIOS
> enabled the VBIOS ROM and copied it to C000. This is
> the "shadow BIOS" option.
> 

So the steps needed would be:

1.  scan for pci devices looking for the vga controller type

2.  if 1 is found other than the primary, disable the current controller

3.  write to PCI config space of secondary controller the address you
want it to appear (ie C000:0000).  Can I use other addresses?

4. enable the controller

5. far call c000:0003

6. disable the controller

7. repeat

Besides the finer points, did I miss anything obvious?

Tony 

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[<sy...@sc...>]

On Thu, Mar 13, 2003 at 01:38:19AM +0800, Antonino Daplas wrote:
> Matrox users are the fortunate few since the author implemented an i2c
> backend.

;)

> That's okay.  The get_EDID() function can get the EDID block several
> ways.
>=20
> 1.  via the driver if it has its own method of getting the EDID block
> (1st choice)
>=20
> 2.  via userland - EDID block (ie get-edid > edid.dmp) uploaded to
> driver via ioctl (2nd choice)
>=20
> 3.  through an arch-specific method -- VBE for x86, OF for PPC, etc
> (last choice)
>=20
> When a user changes monitors without rebooting, he/she can upload an
> edid block appropriate for the display.

Sounds good.

BTW are there public docs available about EDID & DDC? VESA doesn't like
poor open-source developers :(

--=20
Ville Syrj=E4l=E4
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Jon S. <jon...@ya...>]

--- Antonino Daplas <ad...@po...> wrote:
> Unless I missed some imported BIOS calls or other
> methods to do this or
> something similar in real-mode...

You missed something. The address of the VBIOS ROM can
be controlled by writing to the PCI config space. You
can make the ROM appear anywhere you want it to.

This happens even for the boot video device. 
Somewhere very early in the boot the system BIOS
enabled the VBIOS ROM and copied it to C000. This is
the "shadow BIOS" option.



=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 07:42, Jon Smirl wrote:
> --- Antonino Daplas <ad...@po...> wrote:
> > Yikes!  No, it can't be done this way.  During the
> > early boot sequence,
> > the kernel is not yet decompressed and loaded, so
> > all the services the
> > kernel provides are still unavailable.  Unless you
> > want to walk, detect,
> > enable, etc the PCI subsystem in pure 16-bit
> > assembly...
> 
> You don't Linux to look at the PCI subsys you make
> calls into the system BIOS to find the devices.

That's not the only reason.  The problem is in 16-bit mode, the code can
only access an address range up to only 1MB.  PCI resources are located
above 16MB.  So in order to copy the ROM, it might be necessary to
switch to 32-bit mode, copy the ROM, switch back to 16-bit mode, etc.

Unless I missed some imported BIOS calls or other methods to do this or
something similar in real-mode...

Tony

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 20:10, Ville Syrj=E4l=E4 wrote:
> On Tue, Mar 11, 2003 at 08:49:46PM +0800, Antonino Daplas wrote:
> > Hi,
> >=20
> > I was wondering how to get the EDID block, and my first thought was to
> > implement DDC.  But it is tricky to implement,
>=20
> Forgive my ignorance but why is it tricky? As I understand it DDC1 only
> involves reading from the monitor or does EDID require something more?

It will require that each driver provide a means of getting the EDID
from the monitor, either via i2c or by some hardware specific means.
Matrox users are the fortunate few since the author implemented an i2c
backend.

>=20
> Reading stuff from my monitor via /dev/i2c works fine with matroxfb. I
> just tried this and I can see my monitors model in the returned data but
> parse-edid doesn't understand the data so I'm not sure it's the EDID.
>=20
> Also the BIOS solution will fail when someone decides to change their
> monitor. This got me thinking that with a real DDC solution would it be
> feasible to have the driver re-read the EDID periodically and/or on mode
> switch to prevent using bad modes?
>=20

That's okay.  The get_EDID() function can get the EDID block several
ways.

1.  via the driver if it has its own method of getting the EDID block
(1st choice)

2.  via userland - EDID block (ie get-edid > edid.dmp) uploaded to
driver via ioctl (2nd choice)

3.  through an arch-specific method -- VBE for x86, OF for PPC, etc
(last choice)

When a user changes monitors without rebooting, he/she can upload an
edid block appropriate for the display.

Tony

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Jon S. <jon...@ya...>]

The tricky part is getting the DDC data from inside a
device driver as opposed to a user mode app. Plus, not
all cards support the I2C bus, some use other means
that are hidden by the BIOS.


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Some questions

[Michel <mi...@da...>]

On Mit, 2003-03-12 at 09:24, Geert Uytterhoeven wrote:
> On 12 Mar 2003, Michel [ISO-8859-1] Dänzer wrote:
> > On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > > > 
> > > > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > > > aty, radeon, etc can turn this on).
> > > > > > 
> > > > > > What exactly is a "trusted" console?
> > > > > 
> > > > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > > > we can safely assume that the hardware state is still sane, and if not,
> > > > > assume the hardware state is undefined.
> > > > 
> > > > Can you also detect when the app has opened the framebuffer device, and
> > > > assume it's playing nice when it has? (for Option "UseFBDev")
> > > 
> > > X using fbdev will also have the same limitation. I have implemented
> > > something like this before.  For each fb_open, the current->pid can be
> > > saved into a "white list" and removed for each fb_close.  fbcon can then
> > > compare this to the pid of the vt it's switching from.
> 
> The application cannot play not nice unless it mmap()s the MMIO registers. To
> be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_flags.

X will map the MMIO registers with Option "UseFBDev" and still play nice
(hopefully :).

> > > This is becoming to sound very ugly though.  I guess, the best way is to
> > > really support Option "UseFBDev", or at least have the user decide if
> > > he/she wants to have the hardware refreshed.  
> > 
> > I'm afraid I don't understand what you're saying here.
> 
> But I think you do agree :-) He says that if fbdev is active, the X server has
> to be fbdev compliant and thus not mess with the hardware where it's not
> allowed to.

I agree that's how it should be.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[<sy...@sc...>]

On Tue, Mar 11, 2003 at 08:49:46PM +0800, Antonino Daplas wrote:
> Hi,
>=20
> I was wondering how to get the EDID block, and my first thought was to
> implement DDC.  But it is tricky to implement,

Forgive my ignorance but why is it tricky? As I understand it DDC1 only
involves reading from the monitor or does EDID require something more?

Reading stuff from my monitor via /dev/i2c works fine with matroxfb. I
just tried this and I can see my monitors model in the returned data but
parse-edid doesn't understand the data so I'm not sure it's the EDID.

Also the BIOS solution will fail when someone decides to change their
monitor. This got me thinking that with a real DDC solution would it be
feasible to have the driver re-read the EDID periodically and/or on mode
switch to prevent using bad modes?

--=20
Ville Syrj=E4l=E4
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-devel] Some questions

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

On 12 Mar 2003, Michel [ISO-8859-1] D=E4nzer wrote:
> On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 08:07, Michel D=E4nzer wrote:
> > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > >=20
> > > > > > I actually prefer #3, and I already have working code for thi=
s.  We can
> > > > > > also make this driver switchable (ie, drivers that are not af=
fected by X
> > > > > > can disable this, and only drivers that are affected such as =
the riva,
> > > > > > aty, radeon, etc can turn this on).
> > > > >=20
> > > > > What exactly is a "trusted" console?
> > > >=20
> > > > By default, the pid of each vt is -1.  When X loads, it installs =
its own
> > > > VT (ie vt7), which in that case the pid of that particular vt =3D=
=3D X's
> > > > pid.  We can check this pid, and if switching from a vt with pid =
=3D=3D -1,
> > > > we can safely assume that the hardware state is still sane, and i=
f not,
> > > > assume the hardware state is undefined.
> > >=20
> > > Can you also detect when the app has opened the framebuffer device,=
 and
> > > assume it's playing nice when it has? (for Option "UseFBDev")
> >=20
> > X using fbdev will also have the same limitation. I have implemented
> > something like this before.  For each fb_open, the current->pid can b=
e
> > saved into a "white list" and removed for each fb_close.  fbcon can t=
hen
> > compare this to the pid of the vt it's switching from.

The application cannot play not nice unless it mmap()s the MMIO registers=
. To
be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_fla=
gs.

> > This is becoming to sound very ugly though.  I guess, the best way is=
 to
> > really support Option "UseFBDev", or at least have the user decide if
> > he/she wants to have the hardware refreshed. =20
>=20
> I'm afraid I don't understand what you're saying here.

But I think you do agree :-) He says that if fbdev is active, the X serve=
r has
to be fbdev compliant and thus not mess with the hardware where it's not
allowed to.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

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

[Linux-fbdev-devel] Decoding DDC/EDID

[Jon S. <jon...@ya...>]

There is existing code for this the XFree/DRI tree.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/ddc/

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

[Linux-fbdev-devel] real mode entry points for PCI BIOS

[Jon S. <jon...@ya...>]

http://www.delorie.com/djgpp/doc/rbinter/ix/1A/B1.html
The class for video displays is 3

It should be possible to make this work. Do you have a
PCI video card that you can install along with an AGP
one? Future PCI-X allows as many video cards as you
want so we need something along these lines. This
would also solve a lot of problems in framebuffer
development.

The reset program I sent earlier shows how to disable
VGA ports and copy INT vectors, etc. It also shows how
to enable the ROMs (writing to PCI config space).
Video ROMs needs to be copied to RAM before being
executed or they won't run. The BIOS did this to the
primary adapter's ROM for you.

Is it possible to allocate an entire page for DDC
info? At 512 bytes that would support eight video
cards. When the framebuffer driver loads how is it
going to find the page with the DDC info? How does it
know which info goes to which card?

This approach should work crossplatform. The
equivalent code will need to be written for each architecture.

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Some questions

[Michel <mi...@da...>]

On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > 
> > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > aty, radeon, etc can turn this on).
> > > > 
> > > > What exactly is a "trusted" console?
> > > 
> > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > we can safely assume that the hardware state is still sane, and if not,
> > > assume the hardware state is undefined.
> > 
> > Can you also detect when the app has opened the framebuffer device, and
> > assume it's playing nice when it has? (for Option "UseFBDev")
> > 
> 
> X using fbdev will also have the same limitation. I have implemented
> something like this before.  For each fb_open, the current->pid can be
> saved into a "white list" and removed for each fb_close.  fbcon can then
> compare this to the pid of the vt it's switching from.

I see, makes sense.

> This is becoming to sound very ugly though.  I guess, the best way is to
> really support Option "UseFBDev", or at least have the user decide if
> he/she wants to have the hardware refreshed.  

I'm afraid I don't understand what you're saying here.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 08:07, Michel D=E4nzer wrote:
> On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > >=20
> > > > I actually prefer #3, and I already have working code for this.  We=
 can
> > > > also make this driver switchable (ie, drivers that are not affected=
 by X
> > > > can disable this, and only drivers that are affected such as the ri=
va,
> > > > aty, radeon, etc can turn this on).
> > >=20
> > > What exactly is a "trusted" console?
> >=20
> > By default, the pid of each vt is -1.  When X loads, it installs its ow=
n
> > VT (ie vt7), which in that case the pid of that particular vt =3D=3D X'=
s
> > pid.  We can check this pid, and if switching from a vt with pid =3D=3D=
 -1,
> > we can safely assume that the hardware state is still sane, and if not,
> > assume the hardware state is undefined.
>=20
> Can you also detect when the app has opened the framebuffer device, and
> assume it's playing nice when it has? (for Option "UseFBDev")
>=20

X using fbdev will also have the same limitation. I have implemented
something like this before.  For each fb_open, the current->pid can be
saved into a "white list" and removed for each fb_close.  fbcon can then
compare this to the pid of the vt it's switching from.

This is becoming to sound very ugly though.  I guess, the best way is to
really support Option "UseFBDev", or at least have the user decide if
he/she wants to have the hardware refreshed. =20

Tony  =20

Re: [Linux-fbdev-devel] Some questions

[Michel <mi...@da...>]

On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > 
> > > I actually prefer #3, and I already have working code for this.  We can
> > > also make this driver switchable (ie, drivers that are not affected by X
> > > can disable this, and only drivers that are affected such as the riva,
> > > aty, radeon, etc can turn this on).
> > 
> > What exactly is a "trusted" console?
> 
> By default, the pid of each vt is -1.  When X loads, it installs its own
> VT (ie vt7), which in that case the pid of that particular vt == X's
> pid.  We can check this pid, and if switching from a vt with pid == -1,
> we can safely assume that the hardware state is still sane, and if not,
> assume the hardware state is undefined.

Can you also detect when the app has opened the framebuffer device, and
assume it's playing nice when it has? (for Option "UseFBDev")


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Jon S. <jon...@ya...>]

Check out:

arch/i386/pci/pcbios.c

http://members.datafast.net.au/dft0802/specs/bios21.pdf

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Jon S. <jon...@ya...>]

--- Antonino Daplas <ad...@po...> wrote:
> Yikes!  No, it can't be done this way.  During the
> early boot sequence,
> the kernel is not yet decompressed and loaded, so
> all the services the
> kernel provides are still unavailable.  Unless you
> want to walk, detect,
> enable, etc the PCI subsystem in pure 16-bit
> assembly...

You don't Linux to look at the PCI subsys you make
calls into the system BIOS to find the devices.

> 
> Tony
> 


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
> The accel engine is probably not a problem if it uses mmio.  However,
> engines that use command buffers are more susceptible to this if the
> buffers can be dynamically allocated by the process.

OK, ack.

> 
> The i810 for instance uses ringbuffers.  It has to be dynamically
> allocated via agpgart.  Fortunately, the i810 can support 2 ringbuffers,
> so X can use one and fb the other, so there's no conflict. 
> 
> Then you also have DRI joining in the confusion :-)

Not in my case :) The SiS DRI stuff is made in a way to prevent problems 
of this kind. But I ack that it might be on others.

> The best solution, personally, is to have one module controlling chipset
> access -- DRM for 2D and 3D, and fb for video mode switching.

Well. I personally don't want every graphics application to depend on 
kernel modules.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...          *** http://www.winischhofer.net

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 06:54, Jon Smirl wrote:
> --- Antonino Daplas <ad...@po...> wrote:
> > On Wed, 2003-03-12 at 06:05, Jon Smirl wrote:
> > > If your in messing with the early boot sequence,
> > why
> > > don't you make the kernel initialize all of the
> > video
> > > cards in the system instead of only the primary
> > one.
> > 
> > Because I don't know how to :)?  It basically just
> > involves a far call
> > no, if we know where the VBIOS code actually starts?
> 
> It is more complicated. You need to call the PCI Bios
> to find the video cards by their PCI class. There is
> already code in the kernel that calls PCIBios.
> arch/i386/pci/*
> 
> Then you need to one by one map their ROMs (via PCI
> config registers) into C000:0 and call C000:3. But as
> you swap out the other adapters you need to disable
> their VGA emulation as there can only be on VGA device
> per system.  By default the VBIOS code will enable VGA
> emulation on all of the adapters and they won't. You
> also need to record the INT vectors and make sure they
> get set back to the primary ones.
> 

Yikes!  No, it can't be done this way.  During the early boot sequence,
the kernel is not yet decompressed and loaded, so all the services the
kernel provides are still unavailable.  Unless you want to walk, detect,
enable, etc the PCI subsystem in pure 16-bit assembly...

Tony

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 06:27, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > Unfortunately, this is what we are trying to prevent.  X assumes that
> > the console is in text mode, so only registers that affect text mode are
> > restored.  Frequently, cursor registers and bitmaps, as an example, are
> > not refreshed.  There's probably more, ie accel engine, etc.
> 
> Argh.. of course, cursor and accelerator registers are usually not 
> restored, you're right at this. But the drivers usually leave the engine 
> in the same state as when started. (A "restore" of accelerator engine 
> registers is mostly impossible, because a complete restore would cause 
> the last command to be executed again)
> 

The accel engine is probably not a problem if it uses mmio.  However,
engines that use command buffers are more susceptible to this if the
buffers can be dynamically allocated by the process.

The i810 for instance uses ringbuffers.  It has to be dynamically
allocated via agpgart.  Fortunately, the i810 can support 2 ringbuffers,
so X can use one and fb the other, so there's no conflict. 

Then you also have DRI joining in the confusion :-)

The best solution, personally, is to have one module controlling chipset
access -- DRM for 2D and 3D, and fb for video mode switching.

Tony

Re: [Linux-fbdev-devel] Some questions

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > 
> > I actually prefer #3, and I already have working code for this.  We can
> > also make this driver switchable (ie, drivers that are not affected by X
> > can disable this, and only drivers that are affected such as the riva,
> > aty, radeon, etc can turn this on).
> 
> What exactly is a "trusted" console?
> 

By default, the pid of each vt is -1.  When X loads, it installs its own
VT (ie vt7), which in that case the pid of that particular vt == X's
pid.  We can check this pid, and if switching from a vt with pid == -1,
we can safely assume that the hardware state is still sane, and if not,
assume the hardware state is undefined.

Tony

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Jon S. <jon...@ya...>]

--- Antonino Daplas <ad...@po...> wrote:
> On Wed, 2003-03-12 at 06:05, Jon Smirl wrote:
> > If your in messing with the early boot sequence,
> why
> > don't you make the kernel initialize all of the
> video
> > cards in the system instead of only the primary
> one.
> 
> Because I don't know how to :)?  It basically just
> involves a far call
> no, if we know where the VBIOS code actually starts?

It is more complicated. You need to call the PCI Bios
to find the video cards by their PCI class. There is
already code in the kernel that calls PCIBios.
arch/i386/pci/*

Then you need to one by one map their ROMs (via PCI
config registers) into C000:0 and call C000:3. But as
you swap out the other adapters you need to disable
their VGA emulation as there can only be on VGA device
per system.  By default the VBIOS code will enable VGA
emulation on all of the adapters and they won't. You
also need to record the INT vectors and make sure they
get set back to the primary ones.

> Note that this will still be arch-specific. 
> Separate non-primary card
> initialization code for each arch is still
> necessary.

Having X86 work is better than nothing.

> Again, most BIOS code cannot run in protected mode,
> so we need to
> emulate a real-mode environment for them.  It's
> doubtful that Linus
> would want that in his kernel.  Our only chance to
> do this is during
> early boot, or in user space.

The right answer is to get the vendors to give us the
info and then write protected mode versions of
reset/DDC into the fb drivers. Until they do this
everything else is a major hack.

It is not possible to enter VM86 mode from a device
driver. Only two choices are: early boot time or as a
user app.  I have to send you the app directly, it is
too big for SF list.

Early boot time may be a better solution. A complete
implementation would reset all video adapters in the
system and record their DDC info for retrieval by the
FB drivers.

> Tony
> 
> 

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 06:05, Jon Smirl wrote:
> If your in messing with the early boot sequence, why
> don't you make the kernel initialize all of the video
> cards in the system instead of only the primary one.

Because I don't know how to :)?  It basically just involves a far call
no, if we know where the VBIOS code actually starts?  

Note that this will still be arch-specific.  Separate non-primary card
initialization code for each arch is still necessary.

> 
> Alsom is it really better to continue messing with
> these real mode X86 BIOS calls, or would it just be
> better to try and extract the info from the card
> vendors on how to do reset or get the DDC info? If we

Initialization can only be done in real mode.  Once the kernel is in
protected mode, BIOS code cannot be run again (without extreme
difficulty), so resetting is out of the question.

Unfortunately, we don't have info from manufacturers, so we rely on some
standards, such as VESA, to do it transparently for us.  Still VESA code
is mostly 16-bit.

> had the info about the cards we could just ignore the
> VBIOS and write this code into the protected mode FB
> drivers where it belongs. This problem just keeps
> recurring over and over on the non-X86 platforms; it's
> stupid having to carry around an X86 emulator just to
> run the VBIOS code.

Again, most BIOS code cannot run in protected mode, so we need to
emulate a real-mode environment for them.  It's doubtful that Linus
would want that in his kernel.  Our only chance to do this is during
early boot, or in user space.

> 
> I have a user space program that can reset secondary
> cards using their VBIOS and emulating X86 real mode.
> It can probably be easily modified to get the DDC info
> and then IOCTL it into the fb driver. I'll post it if
> you want.
> 

Yes, let me see what I can do.

Tony

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
> Unfortunately, this is what we are trying to prevent.  X assumes that
> the console is in text mode, so only registers that affect text mode are
> restored.  Frequently, cursor registers and bitmaps, as an example, are
> not refreshed.  There's probably more, ie accel engine, etc.

Argh.. of course, cursor and accelerator registers are usually not 
restored, you're right at this. But the drivers usually leave the engine 
in the same state as when started. (A "restore" of accelerator engine 
registers is mostly impossible, because a complete restore would cause 
the last command to be executed again)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...          *** http://www.winischhofer.net

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
>>>2. do not refresh unless var changed - fasted but can result in
>>>corruption/crash if registers were changed behind the back of fbdev
>>
>>I think one can rely on tidyness of applications changing the registers. 
>>Like X does.
> 
>  
> Unfortunately, this is what we are trying to prevent.  X assumes that
> the console is in text mode, so only registers that affect text mode are
> restored.  Frequently, cursor registers and bitmaps, as an example, are
> not refreshed.  There's probably more, ie accel engine, etc.

That surprises me. The X drivers I looked at (quite a bunch) restore all 
registers (that need to be restored, that is)

>>>3. selective refresh - do not refresh if switching between "trusted"
>>>consoles, refresh if switching from "untrusted" consoles.
>>
> 
> I actually prefer #3, and I already have working code for this.  We can
> also make this driver switchable (ie, drivers that are not affected by X
> can disable this, and only drivers that are affected such as the riva,
> aty, radeon, etc can turn this on).

What exactly is a "trusted" console?

Thomas


-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...          *** http://www.winischhofer.net