who sets boot_params[].screen_info.orig_video_isVGA?

who sets boot_params[].screen_info.orig_video_isVGA?

[gl]

Hi all,

I am trying to get intelfb running on a system with a 855GM onboard chip, 
and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line 
814:

 	if (FIXED_MODE(dinfo) && ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
 		ERR_MSG("Video mode must be programmed at boot time.\n");
 		cleanup(dinfo);
 		return -ENODEV;
 	}

The FIXED_MODE(dinfo) test is true, because the board has a LCD connected 
to it, now, why is ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB and is there any 
way to set the type to VIDEO_TYPE_VLFB? ORIG_VIDEO_ISVGA is defined in 
tty.h as

#define ORIG_VIDEO_ISVGA	(screen_info.orig_video_isVGA)

and screen_info is populated in setup.c::setup_arch() as

  	screen_info = SCREEN_INFO;

where SCREEN_INFO is defined in include/asm-i386/setup.h as

extern unsigned char boot_params[PARAM_SIZE];

#define PARAM	(boot_params)
#define SCREEN_INFO (*(struct screen_info *) (PARAM+0))

Now, what do I do with that? I couldn't get my analysis behind this point. 
It doesn't seem to be set up by the bootloader. Who sets this field(s), 
how can one force isVGA to the needed value and is this the correct way to 
get the driver to initialise at all? Is the test in intelfbdrv.c actually 
correct? And this

#define SCREEN_INFO (*(struct screen_info *) (PARAM+0))
#define EXT_MEM_K (*(unsigned short *) (PARAM+2))

in setup.h looks somewhat strange, unless, of course, it is not some 
16-bit mode...

Thanks in advance
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: who sets boot_params[].screen_info.orig_video_isVGA?

[Matthew Garrett]

gl@dsa-ac.de <gl@dsa-ac.de> wrote:
> Hi all,
> 
> I am trying to get intelfb running on a system with a 855GM onboard chip, 
> and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line 
> 814:
> 
>  	if (FIXED_MODE(dinfo) && ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
>  		ERR_MSG("Video mode must be programmed at boot time.\n");
>  		cleanup(dinfo);
>  		return -ENODEV;
>  	}

This ought to be done by the bootloader if you pass a vga=foo argument.
The framebuffer driver doesn't know how to switch resolutions (primarily
because Intel won't tell anyone how to do it, so the only method is a
real-mode BIOS call to the VESA BIOS)

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: who sets boot_params[].screen_info.orig_video_isVGA?

[gl]

Thanks for the reply, Matthew.

On Mon, 5 Sep 2005, Matthew Garrett wrote:

> gl@dsa-ac.de <gl@dsa-ac.de> wrote:
>> I am trying to get intelfb running on a system with a 855GM onboard chip,
>> and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line
>> 814:
>>
>>  	if (FIXED_MODE(dinfo) && ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
>>  		ERR_MSG("Video mode must be programmed at boot time.\n");
>>  		cleanup(dinfo);
>>  		return -ENODEV;
>>  	}
>
> This ought to be done by the bootloader if you pass a vga=foo argument.
> The framebuffer driver doesn't know how to switch resolutions (primarily
> because Intel won't tell anyone how to do it, so the only method is a
> real-mode BIOS call to the VESA BIOS)

Do I get it right, that, say, if I tell grub to load a kernel and specify 
"vga=xxx" on the kernel command line, grub will interpret it, issue some 
VESA BIOS calls and fill in the screen_info struct? If so, the card often 
supports several modes (VGA, SVGA, VESA, different resolutions, colour 
depths, etc.), right? So, which one will be chosen? Does it depend on the 
specific value I give to "vga="? How do I force VIDEO_TYPE_VLFB (VESA VGA 
in graphic mode) mopde then?

BTW, I didn't find any code in grub that sets up screen_info, or it's very 
well hidden:-)

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: who sets boot_params[].screen_info.orig_video_isVGA?

[Matthew Garrett]

gl@dsa-ac.de <gl@dsa-ac.de> wrote:

> Do I get it right, that, say, if I tell grub to load a kernel and specify 
> "vga=xxx" on the kernel command line, grub will interpret it, issue some 
> VESA BIOS calls and fill in the screen_info struct? If so, the card often 
> supports several modes (VGA, SVGA, VESA, different resolutions, colour 
> depths, etc.), right? So, which one will be chosen? Does it depend on the 
> specific value I give to "vga="? How do I force VIDEO_TYPE_VLFB (VESA VGA 
> in graphic mode) mopde then?

Yup. You probably want to take a look at Documentation/fb/vesafb.txt -
the modes are the same.
-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: who sets boot_params[].screen_info.orig_video_isVGA?

[Antonino A. Daplas]

gl@dsa-ac.de wrote:
> Thanks for the reply, Matthew.
> 
> On Mon, 5 Sep 2005, Matthew Garrett wrote:
> 
>> gl@dsa-ac.de <gl@dsa-ac.de> wrote:
>>> I am trying to get intelfb running on a system with a 855GM onboard
>>> chip,
>>> and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13,
>>> line
>>> 814:
>>>
>>>      if (FIXED_MODE(dinfo) && ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
>>>          ERR_MSG("Video mode must be programmed at boot time.\n");
>>>          cleanup(dinfo);
>>>          return -ENODEV;
>>>      }
>>
>> This ought to be done by the bootloader if you pass a vga=foo argument.
>> The framebuffer driver doesn't know how to switch resolutions (primarily
>> because Intel won't tell anyone how to do it, so the only method is a
>> real-mode BIOS call to the VESA BIOS)
> 
> Do I get it right, that, say, if I tell grub to load a kernel and
> specify "vga=xxx" on the kernel command line, grub will interpret it,
> issue some VESA BIOS calls and fill in the screen_info struct? If so,
> the card often supports several modes (VGA, SVGA, VESA, different
> resolutions, colour depths, etc.), right? So, which one will be chosen?
> Does it depend on the specific value I give to "vga="? How do I force
> VIDEO_TYPE_VLFB (VESA VGA in graphic mode) mopde then?
> 
> BTW, I didn't find any code in grub that sets up screen_info, or it's
> very well hidden:-)

One good method is to use the "vesa" driver of Xorg/Xfree86.  Check
/var/log/X*.log and it should have a nice list of vesa mode id's that
are supported.

Then add 0x200 to any of them and use it in your vga= parameter.

Tony 

Re: who sets boot_params[].screen_info.orig_video_isVGA?

[gl]

On Mon, 5 Sep 2005, Matthew Garrett wrote:

> Yup. You probably want to take a look at Documentation/fb/vesafb.txt -
> the modes are the same.

Great, thanks! I tried VESA 0x111 (Linux 0x311) - it is also what is used 
by xfree86 vesa driver, after I've followed the suggestion from Tony 
(cc'ed and quoted below) and tried X with vesa. The kernel boots, intelfb 
driver doesn't exit, I can even start X over fb and it runs! But:

1) both screens - LCD and CRT bocome black as soon as intelfb takes over 
and stay that way also under X

2) kernel logs fill with

intelfb: the cursor was killed - restore it !!
intelfb: size 8, 16   pos 0, 464

Buggy video BIOS?...

On Tue, 6 Sep 2005, Antonino A. Daplas wrote:

> One good method is to use the "vesa" driver of Xorg/Xfree86.  Check
> /var/log/X*.log and it should have a nice list of vesa mode id's that
> are supported.
>
> Then add 0x200 to any of them and use it in your vga= parameter.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: who sets boot_params[].screen_info.orig_video_isVGA?

[Antonino A. Daplas]

gl@dsa-ac.de wrote:
> On Mon, 5 Sep 2005, Matthew Garrett wrote:
> 
>> Yup. You probably want to take a look at Documentation/fb/vesafb.txt -
>> the modes are the same.
> 
> Great, thanks! I tried VESA 0x111 (Linux 0x311) - it is also what is
> used by xfree86 vesa driver, after I've followed the suggestion from
> Tony (cc'ed and quoted below) and tried X with vesa. The kernel boots,
> intelfb driver doesn't exit, I can even start X over fb and it runs! But:
> 
> 1) both screens - LCD and CRT bocome black as soon as intelfb takes over
> and stay that way also under X
> 
> 2) kernel logs fill with
> 
> intelfb: the cursor was killed - restore it !!
> intelfb: size 8, 16   pos 0, 464
> 
> Buggy video BIOS?...

There might be a bug with the ioremap patch that got in by the time
linux-2.6.13 was released. The intelfb maintainer is still working on it.
You can try to revert that patch (just make sure that the graphics
aperture in the BIOS is set to <= 128MB) or use vesafb for now.

Here's the link to that patch:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=6bd49341f2806168c877e12cefca77b93437bac2;hp=89204c40a03346cd951e698d854105db4cfedc28

Tony

input/touchscreen (was Re: who sets boot_params[].screen_info.orig_video_isVGA?)

[gl]

On Tue, 6 Sep 2005, Antonino A. Daplas wrote:

> There might be a bug with the ioremap patch that got in by the time
> linux-2.6.13 was released. The intelfb maintainer is still working on it.
> You can try to revert that patch (just make sure that the graphics
> aperture in the BIOS is set to <= 128MB) or use vesafb for now.
>
> Here's the link to that patch:
>
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=6bd49341f2806168c877e12cefca77b93437bac2;hp=89204c40a03346cd951e698d854105db4cfedc28

Indeed, reverting this patch I get fb, but I still get those "cursor was 
killed" messages permanently, and, indeed, there is no cursos, and 
starting X over fb produces:

(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed

Actually, I did manage to get it working with vesafb in 0x111 mode and X 
over it. So far so good. Now to my actual task - touchscreen... We are 
using UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the 
screen, some bytes come out, but that's about all I can say. I guess, it 
should be used with summa protocol, right? X doesn't want to accept summa 
device as a core pointer, gpm -t summa produces only errors:

Error in read()ing first: No such file or directory

from strace looke like it cannot write to it:

6977  open("/dev/input/ts0", O_RDWR|O_NONBLOCK) = 0
6977  fcntl64(0, F_GETFL)               = 0x802 (flags O_RDWR|O_NONBLOCK)
6977  fcntl64(0, F_SETFL, O_RDWR)       = 0
6977  ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9bb56c) = -1 EINVAL (Invalid argument)
6977  ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9bb53c) = -1 EINVAL (Invalid argument)
6977  ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B9600 -opost -isig -icanon -echo ...}) = -1 EINVAL (Invalid argument)
6977  write(0, "*q", 2)                 = -1 EINVAL (Invalid argument)
6977  nanosleep({0, 100000000}, NULL)   = 0
6977  ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9bb53c) = -1 EINVAL (Invalid argument)
6977  ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B9600 -opost -isig -icanon -echo ...}) = -1 EINVAL (Invalid argument)
6977  write(0, NULL, 1)                 = -1 EINVAL (Invalid argument)
6977  nanosleep({0, 400000000}, NULL)   = 0
6977  write(0, "B", 1)                  = -1 EINVAL (Invalid argument)
6977  write(0, "z?", 2)                 = -1 EINVAL (Invalid argument)
6977  select(1024, [0], NULL, NULL, {0, 200000}) = 0 (Timeout)
6977  write(0, NULL, 1)                 = -1 EINVAL (Invalid argument)
6977  nanosleep({0, 400000000}, NULL)   = 0
...

and reading from it doesn't get any bytes:

6977  select(2, [0 1], NULL, NULL, {86400, 0}) = 1 (in [0], left {86400, 0})
6977  open("/dev/tty0", O_RDONLY)       = 2
6977  ioctl(2, KDGETMODE, 0xbf9bb7d4)   = 0
6977  close(2)                          = 0
6977  read(0, "", 1)                    = 0

It's a completely different topic now, jost in case - any ideas anybody?

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: input/touchscreen (was Re: who sets boot_params[].screen_info.orig_video_isVGA?)

[gl]

On Tue, 6 Sep 2005, gl@dsa-ac.de wrote:

> it. So far so good. Now to my actual task - touchscreen... We are using 
> UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the screen, some

Ok, looks like it is not really supported by the stock kernel... Any 
pointers to wild patches? It should be pretty easy to write one, if we had 
a datasheet...

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: input/touchscreen (was Re: who sets boot_params[].screen_info.orig_video_isVGA?)

[gl]

On Tue, 6 Sep 2005, gl@dsa-ac.de wrote:

> On Tue, 6 Sep 2005, gl@dsa-ac.de wrote:
>
>> it. So far so good. Now to my actual task - touchscreen... We are using 
>> UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the screen, 
>> some
>
> Ok, looks like it is not really supported by the stock kernel... Any pointers 
> to wild patches? It should be pretty easy to write one, if we had a 
> datasheet...

My sincere apologise to SemTech, a datasheet is indeed freely available. 
Any volunteers to cook up a driver, or should I attempt it myself? Just 
that it will take me more time than for somebody, who has done it before.

Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany