Bug 980570 - gfxboot should be more flexible selecting a suitable video mode for itself
gfxboot should be more flexible selecting a suitable video mode for itself
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Minor (vote)
: ---
Assigned To: Steffen Winterfeldt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-18 13:47 UTC by Steffen Winterfeldt
Modified: 2017-12-07 17:36 UTC (History)
3 users (show)

See Also:
Found By: Community User
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
snwint: needinfo? (siro)


Attachments
test iso 1: show available video modes (1.00 MB, application/octet-stream)
2016-05-18 13:50 UTC, Steffen Winterfeldt
Details
result from test iso 1 (28.24 KB, image/jpeg)
2016-05-19 07:03 UTC, Timo Jyrinki
Details
test iso 2: show active vbe mode and try to use it (1.00 MB, application/octet-stream)
2016-05-19 11:32 UTC, Steffen Winterfeldt
Details
result from test iso 2 (36.19 KB, image/jpeg)
2016-05-19 13:33 UTC, Timo Jyrinki
Details
test iso 3: also list available modes (1.00 MB, application/octet-stream)
2016-05-19 14:01 UTC, Steffen Winterfeldt
Details
result from test iso 3 (37.41 KB, image/jpeg)
2016-05-19 14:15 UTC, Timo Jyrinki
Details
test iso 4: just set mode 0x140 (1.00 MB, application/octet-stream)
2016-05-19 14:27 UTC, Steffen Winterfeldt
Details
test iso 5: use framebuffer for drawing (1.00 MB, application/octet-stream)
2016-05-20 08:45 UTC, Steffen Winterfeldt
Details
test iso 6: try very hard to show something (1.00 MB, application/octet-stream)
2016-05-20 13:34 UTC, Steffen Winterfeldt
Details
result from test iso 6 (161.24 KB, image/jpeg)
2016-05-20 13:45 UTC, Timo Jyrinki
Details
test iso 7: try to draw something (1.00 MB, application/octet-stream)
2016-06-08 12:11 UTC, Steffen Winterfeldt
Details
result from test iso 7 (325.56 KB, image/jpeg)
2016-06-08 17:29 UTC, Timo Jyrinki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steffen Winterfeldt 2016-05-18 13:47:31 UTC
See https://github.com/openSUSE/gfxboot/issues/7.

It doesn't start on Chromebooks as it doesn't find/can't set a video mode.
Comment 1 Steffen Winterfeldt 2016-05-18 13:50:16 UTC
Created attachment 677455 [details]
test iso 1: show available video modes

Please use this ('dd' to a usb stick) to show the available video modes.
Comment 2 Timo Jyrinki 2016-05-19 07:03:34 UTC
Created attachment 677518 [details]
result from test iso 1

It just hangs in there.

With kvm /dev/sdb on another machine I can see it correctly gives resolution list.
Comment 3 Steffen Winterfeldt 2016-05-19 07:52:13 UTC
Does it react to 'ESC'? Like showing the text boot menu?
Comment 4 Timo Jyrinki 2016-05-19 08:09:14 UTC
Right, yes it does react to Esc, I can get the boot: menu with the harddisk/linux/upgrade etc options. So it's not hanged.
Comment 5 Steffen Winterfeldt 2016-05-19 08:28:59 UTC
Ok, then everything is fine, actually. I'll put together a new test iso today or tomorrow.
Comment 6 Steffen Winterfeldt 2016-05-19 11:32:43 UTC
Created attachment 677583 [details]
test iso 2: show active vbe mode and try to use it

Please test this one. Ideally it shows the current mode and then lets you continue.

Anything can happen, but I'd like at least to know the mode number.
Comment 7 Timo Jyrinki 2016-05-19 13:33:53 UTC
Created attachment 677602 [details]
result from test iso 2

No graphics still. (but under kvm I got the graphical menu instead of text one)
Comment 8 Steffen Winterfeldt 2016-05-19 14:01:46 UTC
Created attachment 677608 [details]
test iso 3: also list available modes

Please test this one. It should list all available modes on the first text screen. Otherwise nothing has changed.

Please post a screenshot of the mode list (provided there is anything).
Comment 9 Timo Jyrinki 2016-05-19 14:15:52 UTC
Created attachment 677609 [details]
result from test iso 3

We've some modes. The native resolution of Acer Chromebook R11 (Braswell 14nm CPU) is 1366x768.
Comment 10 Steffen Winterfeldt 2016-05-19 14:27:03 UTC
Created attachment 677616 [details]
test iso 4: just set mode 0x140

Ok, then let's just hardcode this mode number an see what happens.
Comment 11 Timo Jyrinki 2016-05-19 17:05:05 UTC
With test iso 4, blank black screen after the "Press a key to continue..." prompt after the modes are displayed as in the previous image attachement. Keypresses don't seem have a visual effect.

(On kvm /dev/sdb, 320x200 graphical output)
Comment 12 Steffen Winterfeldt 2016-05-20 08:45:34 UTC
Created attachment 677696 [details]
test iso 5: use framebuffer for drawing

Please try this one. With some luck it might work.
Comment 13 Timo Jyrinki 2016-05-20 13:06:33 UTC
With test iso 5 still just blank black screen after seeing the text "Initializing gfx code...".
Comment 14 Steffen Winterfeldt 2016-05-20 13:34:44 UTC
Created attachment 677773 [details]
test iso 6: try very hard to show something

Ok, if this one also doesn't show anything I'm out of ideas for the moment.
Comment 15 Timo Jyrinki 2016-05-20 13:45:33 UTC
Created attachment 677776 [details]
result from test iso 6

We have image! Sorry for bad colors, they are normal red/green/blue for all the blocks.

The text is ip 26d: 2010b0a9.4 (ie the '1' is what's barely visible under green color in the photo)
Comment 16 Steffen Winterfeldt 2016-05-20 13:53:53 UTC
And if you press 'ESC' there, what happens?
Comment 17 Timo Jyrinki 2016-05-20 14:04:08 UTC
Nothing seems to happen when I press Esc, the screen stasys as is.
Comment 18 Steffen Winterfeldt 2016-05-20 14:29:36 UTC
Ok, what you see there is the debug window. You can single-step through the code
with 'Enter', 'ESC' leaves the debug mode. The dots were just sprayed all over
the graphics framebuffer.

If you go two steps further with 'Enter' (provided it works), what number appears
in the data window (upper left)? (The ip in the bottom left should show '27a'.)
Comment 19 Steffen Winterfeldt 2016-05-20 15:02:07 UTC
I'm on vacation next week and won't respond during that time.
Comment 20 Timo Jyrinki 2016-05-20 15:26:48 UTC
The number that arrives at the bottom row of data is: 0: 201114ad. c

Below in the bottom box there is also:
err   0
ip   27a:       45.7

Let's continue after next week then probably.
Comment 21 Steffen Winterfeldt 2016-06-08 12:11:29 UTC
Created attachment 680084 [details]
test iso 7: try to draw something

I've prepared a new test image. It shows at startup on a text screen the internal memory layout. Please attach the numbers (or screenshot).

Then, it will draw a bit. On the first debug screen, you should see the dots all over the screen as before + some lines crossing the screen + a small rectangle in the middle.

When you press ESC there, you reach another debug point and the text 'Test' should be printed at the top of the screen.

Do any of these things show up?
Comment 22 Timo Jyrinki 2016-06-08 17:29:10 UTC
Created attachment 680175 [details]
result from test iso 7

The memory layout is shown, but only the image shown in the attachment (below memory layout) is what's gotten after that. Waiting or pressing Esc does not change anything. That is, only the diagonal lines background that was also shown with test iso 6 (aside from top left corner that had other info), with nothing else.

Note that while the background is drawn immediately, any characters outputted are v-e-r-y slow to output, so any timing assumptions may be wrong. As mentioned at https://johnlewis.ie/alls-well-that-braswell/ - if one would have a full screen of text output, it might take a full minute to draw. Think of a 300bps modem line. With short and few lines like with test iso 6, it only took maybe 10-20s or so though.
Comment 23 Steffen Winterfeldt 2016-06-09 11:11:58 UTC
I'm currently out of ideas and it will be tricky to make progress without such a device at my desk. :-(

Issues I've seen:

- the video bios knows only one video mode with an unusual resolution; the standard gfxboot script doesn't expect this (and doesn't provide a theme in this resolution), but that can be trivially adjusted

- it seems that the graphics card can only be accessed via framebuffer; but gfxboot uses the old method via 64k windows mapped at 0xa0000 for drawing; I've added a patch that changes this (see link below) - and which works at least on some test machines

- it still doesn't work here; the patch seems to be ok because you can (a) draw directly by using the framebuffer pointer and do memory writes (the dots you see with the test isos) and (b) the debug window is visible (it's drawn using standard internal routines)

- my suspicion atm is that _reading_ from the framebuffer causes problems: it's done implicitly internally at a number of places and can't be avoided (design decision from the old times where free memory was scarce); also, maybe strange mtrr settings are an issue

I've put the current state into the chrome_fb branch (there's some translation update that slipped into it which can be ignored). When you build the 'test_fb' theme, you basically get test iso 7.

https://github.com/openSUSE/gfxboot/tree/chrome_fb
Comment 24 Timo Jyrinki 2016-06-10 06:06:01 UTC
Thank you for the investigation! It seems valuable information nevertheless.

In case budget for extra hardware is found, for example this particular Chromebook is the 4GB/32GB model at https://www.amazon.de/Acer-Chromebook-CB5-132T-C732-Convertible-Quad-Core/dp/B01618Z3R4/278-3649416-4927750

I bought it for experimentation myself, since it has some interesting features like Coreboot (like all Chromebooks), touch screen, 14nm CPU with modern GPU features (Broadwell like) and 4GB RAM which is useful amount.
Comment 25 Patrick Rudolph 2017-05-28 16:22:06 UTC
gfxboot doesn't support 24bpp or 32bpp.

The only mode that is supported by coreboot's native graphics initialization is 32bpp.

As the graphics initialization is done by coreboot, the pixel format can't be changed in (Sea)VGABIOS.

I'm working on supporting multiple resolutions, but the main problem persists. There will be only one advertised pixel format ever.
Comment 26 Steffen Winterfeldt 2017-05-29 06:51:22 UTC
gfxboot supports 32bit but not 24bit.
Comment 27 Patrick Rudolph 2017-05-29 15:23:08 UTC
You are right.
I got confused looking at the code:
pixel_bits		db 0		; pixel size (8 or 16)
color_bits		db 0		; color bits (8, 15 or 16)

This should be fixed.

SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the VBE format should be 32bpp. I'll send a fix to SeaBIOS.
Comment 28 Patrick Rudolph 2017-05-29 15:58:28 UTC
I found another issue:
I tested KDE Neon Live DVD. It does not boot because the code checks additional window attributes:

		mov dx,[es:edi+2]		; win A/B attributes
		and dx,707h
		cmp dl,7
		jz set_mode_50		; win A is rw

It depends on VBE_WINDOW_ATTRIBUTE_RELOCATABLE.
The comment indicates that it needs only VBE_WINDOW_ATTRIBUTE_READABLE and VBE_WINDOW_ATTRIBUTE_WRITEABLE.

Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ?

It shows a splash screen and boots if I just advertise VBE_WINDOW_ATTRIBUTE_RELOCATABLE without checking what's it's good for.
Comment 29 Steffen Winterfeldt 2017-05-30 07:49:21 UTC
> SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the
> VBE format should be 32bpp. I'll send a fix to SeaBIOS.

Uhm, is there a way to detect this situation? Like, add at least the color mask
bits up to 32?

> Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ?

Good point. It isn't.
Comment 30 Patrick Rudolph 2017-05-30 10:09:31 UTC
(In reply to Steffen Winterfeldt from comment #29)
> > SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the
> > VBE format should be 32bpp. I'll send a fix to SeaBIOS.
> 
> Uhm, is there a way to detect this situation? Like, add at least the color
> mask
> bits up to 32?
Yes that should be working, but all VBE clients expect the bpp to match the accumulated color bit mask.

I've sent a fix to SeaBIOS.

> 
> > Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ?
> 
> Good point. It isn't.
Looking at the code is seems that relocation is required as the "window" has a maximum pagesize of 64K, but I'm not familar with those addressing modes.

In VBE2.0 there's a linear framebuffer that does not need relocations at all and it's the only mode supported by coreboot's SeaVGABios implementation.

Would it be possible to add VBE2 and linear framebuffer support to gfxboot ?
Comment 31 Steffen Winterfeldt 2017-05-30 11:09:27 UTC
> Looking at the code is seems that relocation is required

You're right; after reading up the vbe specs again, 'relocation' means
mapping different regions into the window. So yes, it's required and the
code is correct.

> Would it be possible to add VBE2 and linear framebuffer support to gfxboot?

Yes, I've done this in the branch mentioned in comment 23. The patch basically
simulates the 64k window thing by moving 64k segment selectors across the framebuffer.
Comment 32 Patrick Rudolph 2017-06-13 17:45:29 UTC
My patches made it into SeaBios git.
Following points are fixed:
* Advertise 32bpp instead of 24bpp
* Advertise additional VBE modes

I tried your examples but I'm not sure what they want to show, and pressing ESC doesn't work. It looks like it crashes.

Is there anything I can help at ?
Comment 33 Steffen Winterfeldt 2017-06-14 13:40:56 UTC
I don't see any reason why the code in the chrome_fb branch shouldn't work. It does, for example, work in qemu as running './gfxtest -t test_fb' shows.

From Timo's reports it seems it gets the framebuffer address right: the code in
themes/test_fb/test_fb.bc that draws directly by writing bytes into the fb and creates the diagonal pixel pattern seemed to work. But then it gets wrong.

I don't have an idea so far, why.
Comment 34 Patrick Rudolph 2017-06-18 07:33:53 UTC
Fixed by https://github.com/openSUSE/gfxboot/pull/25

Tested on real hardware.
Comment 35 Steffen Winterfeldt 2017-06-19 08:42:12 UTC
Thanks a lot!

Then, AIUI, the only thing left is to recognize the video mode as 32bit even though it's advertised as 24bit, right? Can we do that by adding up the
rgb+reserved bits and use this if the sum is > than bits_per_pixel?
Comment 36 Patrick Rudolph 2017-06-19 09:04:46 UTC
If you mind adding a workaround for broken VGABIOS, yes that's the solution.

Please note that the bpp is correctly advertised in SeaBios git.
With the next stable release this issue will be fixed, too.
Comment 37 Steffen Winterfeldt 2017-06-21 12:56:06 UTC
Patrick, if you could try out

https://github.com/openSUSE/gfxboot/pull/26

this would be great. There should be everything in place now.
Comment 38 Steffen Winterfeldt 2017-11-20 12:54:13 UTC
I think it's all in Tumbleweed meanwhile, closing.
Comment 39 Patrick Rudolph 2017-12-07 17:36:52 UTC
My framebuffer fixes are part SeaBIOS 1.11.0 stable.