Hello Linux maintainers,
Firstly, I would like to extend my deepest appreciation for your
dedication the linux project. I use nothing but linux, and am happy to
say, I love it to death.
However, since I've installed 2.6.26, I've noticed what I believe to
be a serious detriment to the community. While in itself, its not
major, if trends like it continue...
Anyhow, I noticed that vesafb is no longer a part of the kernel. I
have debian sid, and its 2.6.26-1 kernel seemed to have
CONFIG_FB_VESA=Y in its config, but it didn't work. So I naturally
compiled my own kernel, making sure to explicitly mark Y for the
option. However, vga=791 still gave a mode not found. After much trial
and error, and googling, I was able to get uvesafb working, however,
it doesn't start until later in the boot sequence (unfavorable), and
also, with splashy, the background image is stretched vertically over
500% showing only an ugly top portion of the image.
Now I could care less about the splash screen, its the principle. I
spent days working on trying different things, researching, and
compiling, all to no avail. I don't understand why you couldn't leave
vesafb in there (and if it is in there, its terribly broken) And
uvesafb is a serious pain to get set up for someone with an advanced
level of experience, and out of reach for newcomers and even those
who've mastered Windoze machines and are fresh converts.
For the time being, I am using 2.6.24, because linux works like its
supposed to here. Right after grub, the framebuffer kicks in (and
while uvesafb might be nice, with extra features, having to wait for
it is not) and next thing I know, splashy works fine, more
importantly, pidgin (finch) and links work in the framebuffer console
(which also work once I finally got uvesafb working, but it was hardly
worth it).
Until uvesafb matures to the point that it can be a valid replacement
for vesafb, don't do it, and when that day comes, let users have a
choice.
Thank you for hearing my concerns, and keep up the good work.
p.s., I'm currently starting work on a patch to get vesafb back up and
working on 2.6.26, but thats neither here nor there, give those that
cannot help themselves with code the choice they come to linux for!
Robert Moss, le Thu 23 Oct 2008 00:54:56 -0700, a ?crit :
> Anyhow, I noticed that vesafb is no longer a part of the kernel.
That's not true. It works nicely on my laptop (though I don't get
the native 1280x800 resolution).
> vga=791 still gave a mode not found.
Then that's a bug, which is a completely different thing. Could you
check that the output of vga=ask and typing scan at the boot prompt is
the same between 2.6.24 and 2.6.25/26??
Samuel, who may want to try 2.6.24 to get his native resolution.
On Thursday 23 October 2008 09:04:59 Samuel Thibault wrote:
> Robert Moss, le Thu 23 Oct 2008 00:54:56 -0700, a ?crit :
> > Anyhow, I noticed that vesafb is no longer a part of the kernel.
>
> That's not true. It works nicely on my laptop (though I don't get
> the native 1280x800 resolution).
>
> > vga=791 still gave a mode not found.
>
> Then that's a bug, which is a completely different thing. Could you
> check that the output of vga=ask and typing scan at the boot prompt is
> the same between 2.6.24 and 2.6.25/26??
It simply isn't true that the vesafb driver has been removed or disabled. Nor
is it true that the vga= video mode selection has been removed or is broken.
I've been using vga=791, too, for years, and on 2.6.26 and 2.6.27 it continues
to work as it always did.
The OP needs to post his config before creating a fuss about removed features
and "lack of choice". From what I can see, such statements simply aren't true.
At worst there is a bug here on one particular system that needs to be fixed.
--
Cheers,
Alistair.
I also want to note, that I downloaded 2.6.27.3 and compiled, with
CONFIG_FB_VESA=Y, and still get excactly the same response as from
2.6.26
Thank you for the quick reply, I'm glad to hear that everything is
still supposed to work ^_^.
Ok on both 2.6.24 AND 2.6.26, i get the same thing from vga=ask then scan,
0 F00 80x25
1 F01 80x50
2 F02 80x43
3 F03 80x28
4 F05 80x36
5 F06 80x36
6 F07 80x60
Please select a number
and on 2.6.26 with vga=791 it says
Screen unavailable [or not found, im not sure] 317. (which i believe
is 0x317 = 791)
On Thu, Oct 23, 2008 at 1:04 AM, Samuel Thibault
<[email protected]> wrote:
> Robert Moss, le Thu 23 Oct 2008 00:54:56 -0700, a ?crit :
>> Anyhow, I noticed that vesafb is no longer a part of the kernel.
>
> That's not true. It works nicely on my laptop (though I don't get
> the native 1280x800 resolution).
>
>> vga=791 still gave a mode not found.
>
> Then that's a bug, which is a completely different thing. Could you
> check that the output of vga=ask and typing scan at the boot prompt is
> the same between 2.6.24 and 2.6.25/26 ?
>
> Samuel, who may want to try 2.6.24 to get his native resolution.
>
Here are my kernel configs if it helps.
24 is default from debian sid,
26 is custom after the debian one didnt work (mine also doesnt work)
27 (custom, from scratch/default from kernel.org, with some drivers i
dont need removed)
On Thu, Oct 23, 2008 at 1:04 AM, Samuel Thibault
<[email protected]> wrote:
> Robert Moss, le Thu 23 Oct 2008 00:54:56 -0700, a ?crit :
>> Anyhow, I noticed that vesafb is no longer a part of the kernel.
>
> That's not true. It works nicely on my laptop (though I don't get
> the native 1280x800 resolution).
>
>> vga=791 still gave a mode not found.
>
> Then that's a bug, which is a completely different thing. Could you
> check that the output of vga=ask and typing scan at the boot prompt is
> the same between 2.6.24 and 2.6.25/26 ?
>
> Samuel, who may want to try 2.6.24 to get his native resolution.
>
On Thursday 23 October 2008 12:21:09 Robert Moss wrote:
> I also want to note, that I downloaded 2.6.27.3 and compiled, with
> CONFIG_FB_VESA=Y, and still get excactly the same response as from
> 2.6.26
Useful info, and I checked your configs and they enable the right options.
Looks like you've found a real bug.
IIRC, a lot of real mode assembler (including the x86 vga/vesa stuff, iirc)
was rewritten a year or so ago, in C. This might have been the time that this
bug was introduced. I've added hpa to CC since I believe he was the author of
these changes.
(Summary of the original report is that vga= vesa mode selection seems to have
broken for Robert since at least 2.6.26, and after 2.6.24. From what I can see
he has the right vesafb options enabled.)
> Screen unavailable [or not found, im not sure] 317. (which i believe
> is 0x317 = 791)
I grepped the tree for "Screen unavailable" and "Screen not found" and found
nothing. Could you please reproduce the message and confirm which exactly it
is?
--
Cheers,
Alistair.
Alistair John Strachan wrote:
> On Thursday 23 October 2008 12:21:09 Robert Moss wrote:
>> I also want to note, that I downloaded 2.6.27.3 and compiled, with
>> CONFIG_FB_VESA=Y, and still get excactly the same response as from
>> 2.6.26
>
> Useful info, and I checked your configs and they enable the right options.
> Looks like you've found a real bug.
>
> IIRC, a lot of real mode assembler (including the x86 vga/vesa stuff, iirc)
> was rewritten a year or so ago, in C. This might have been the time that this
> bug was introduced. I've added hpa to CC since I believe he was the author of
> these changes.
>
> (Summary of the original report is that vga= vesa mode selection seems to have
> broken for Robert since at least 2.6.26, and after 2.6.24. From what I can see
> he has the right vesafb options enabled.)
>
That happend in 2.6.23 I believe, so that would be unrelated.
The best would be to bisect the regression. The second best would be if
he could run the "vesainfo" program from the Syslinux distribution (it's
a pre-boot program that dumps information on the VESA stack). The third
best would be to set up Xorg to run the "vesa" driver, and send
/var/log/Xorg.0.log.
-hpa
Robert Moss, le Thu 23 Oct 2008 04:21:09 -0700, a ?crit :
> Ok on both 2.6.24 AND 2.6.26, i get the same thing from vga=ask then scan,
> 0 F00 80x25
> 1 F01 80x50
> 2 F02 80x43
> 3 F03 80x28
> 4 F05 80x36
> 5 F06 80x36
> 6 F07 80x60
Could you try edd=off?
Samuel
ok, this morning, I turned on my computer, and it gave me the error
message again:
Undefined video mode number: 317
I immediately restarted, and this time appened edd=off to the kernel
line. It started up without incident. But I can't be sure if it was
the appendage that caused it, or if for some reason, it randomly
decided to work, however, because the 2.6.24 kernel never failed me,
and I could never get the other, higher kernels to work (repeatedly) i
believe this may have something to do with it, but of course, i'm not
sure what edd=off does, I would guess enhanced display detection, but
thats just a guess,
On Fri, Oct 24, 2008 at 2:24 AM, Samuel Thibault
<[email protected]> wrote:
> Robert Moss, le Thu 23 Oct 2008 04:21:09 -0700, a ?crit :
>> Ok on both 2.6.24 AND 2.6.26, i get the same thing from vga=ask then scan,
>> 0 F00 80x25
>> 1 F01 80x50
>> 2 F02 80x43
>> 3 F03 80x28
>> 4 F05 80x36
>> 5 F06 80x36
>> 6 F07 80x60
>
> Could you try edd=off?
>
> Samuel
>
Robert Moss wrote:
> ok, this morning, I turned on my computer, and it gave me the error
> message again:
>
> Undefined video mode number: 317
Your VESA BIOS seems to have some serious braindamage (the fact that the
modes don't list at all is evidence of that), but finding out what can
be done to help it would be useful.
Again, a git bisect between v2.6.24 and v2.6.26 would be best:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6.git
git bisect start
git bisect bad v2.6.26
git bisect good v2.6.24
<build and test kernel>
git bisect <good,bad>
<keep going until one commit shows up>
If a commit doesn't build or otherwise exhibit a different problem
(meaning "no info available"), use "git bisect skip".
-hpa