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
[email protected] <[email protected]> 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 | [email protected]
Thanks for the reply, Matthew.
On Mon, 5 Sep 2005, Matthew Garrett wrote:
> [email protected] <[email protected]> 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
[email protected] <[email protected]> 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 | [email protected]
[email protected] wrote:
> Thanks for the reply, Matthew.
>
> On Mon, 5 Sep 2005, Matthew Garrett wrote:
>
>> [email protected] <[email protected]> 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
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
[email protected] 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
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
On Tue, 6 Sep 2005, [email protected] 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
On Tue, 6 Sep 2005, [email protected] wrote:
> On Tue, 6 Sep 2005, [email protected] 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