#11268 closed bug (fixed)
intel_extreme picks wrong display mode at first boot
Reported by: | humdinger | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Graphics/intel_extreme/haswell | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | #14643 | Blocking: | #12007, #17324 |
Platform: | All |
Description
This is hrev47891.
When I boot a pristine nightly image, the intel_extreme driver picks up my chipset, but distorts the picture by squashing it to the first quarter of the panel height.
listdev:
device Display controller (VGA compatible controller, VGA controller) [3|0|0] vendor 8086: Intel Corporation device 0416: 4th Gen Core Processor Integrated Graphics Controller
Should be work-aroundable by booting in safe-mode and changing the screenmode with the Screen preferences. I just took the ~/config/settings/system/app_server/* from a working installation...
Attached the syslog when Haiku picks the wrong mode.
Attachments (5)
Change History (30)
by , 10 years ago
Attachment: | syslog_hrev47891 added |
---|
comment:2 by , 10 years ago
It appears it's not able to fetch EDID information in intel_extreme, likely due to the recent changes in hrev47864.
comment:3 by , 10 years ago
I have had something similar happening with Radeon cards. Attached is a photo (image0182). Is this the same as what you are seeing with Intel video?
by , 10 years ago
Attachment: | IMG_0182.JPG added |
---|
comment:4 by , 10 years ago
Booting the "Discover Haiku" stick (hrev48834), Haiku doesn't scramble the output anymore, but chooses the wrong mode, 1024x768@60Hz. Any try to change the resolution ends up with a scrambled screen. "message /boot/home/config/settings/system/app_server/workspaces" says:
BMessage('asws') { columns = int32(0x3 or 3) rows = int32(0x4 or 4) workspace[0] = BMessage(0x0) { screen[0] = BMessage(0x0) { id = int32(0x0 or 0) vendor = string("DEL", 4 bytes) name = string("DELL U2412M", 12 bytes) product id = int32(0xa079 or 41081) serial = string("M2GCR25N0YEL", 13 bytes) produced week = int32(0x15 or 21) produced year = int32(0x7dc or 2012) frame = BRect(l:0.0, t:0.0, r:1023.0, b:767.0) mode = (type = 'RAWT')(size = 40) } screen[1] = BMessage(0x0) { id = int32(0x0 or 0) frame = BRect(l:0.0, t:0.0, r:1023.0, b:767.0) mode = (type = 'RAWT')(size = 40) } color = int32(0xff000000 or -16777216) }
This is my working "workspaces" that I've been carrying with me for ages now:
BMessage('asws') { columns = int32(0x4 or 4) rows = int32(0x1 or 1) workspace[0] = BMessage(0x0) { screen = BMessage(0x0) { id = int32(0x0 or 0) frame = BRect(l:0.0, t:0.0, r:1919.0, b:1079.0) mode = (type = 'RAWT')(size = 40) } color = int32(0xff986633 or -6789581) } workspace[1] = BMessage(0x0) { screen[0] = BMessage(0x0) { id = int32(0x0 or 0) vendor = string("LGD", 4 bytes) name = string("", 1 bytes) product id = int32(0x323 or 803) serial = string("", 1 bytes) produced week = int32(0x0 or 0) produced year = int32(0x7dc or 2012) frame = BRect(l:0.0, t:0.0, r:1919.0, b:1079.0) mode = (type = 'RAWT')(size = 40) }
Attached both "workspaces" messages in full.
comment:5 by , 10 years ago
Following friend DeadYak's suggestion, I deleted the "workspaces" file and changed modes in "Screen" prefs which creates a new "workspaces". This one doesn't have the wrong vendor string set, but doesn't work either... Attached the resulting "workspaces_non-working_2" file
I then changed the ~/config/kernel/drivers/vesa file from "1024 768 32" to "1920 1080 32". That had me boot to the correct resolution, though it's still scrambled.
by , 10 years ago
Attachment: | workspaces_non-working_2.txt added |
---|
freshly created, non-working "workspaces" file
comment:6 by , 10 years ago
Sorry for spamming this ticket. That first non-working config file apparently has Dane's "DELL U2412M" monitor in it... But of course the newly generated file doesn't work either.
comment:8 by , 10 years ago
I think our modesetting is not completely working for Intel HD 4000 and possibly other new cards. We rely a bit too much on the BIOS and the VESA splash screen setting up most things correctly, but then we are not capable of changing resolutions.
comment:9 by , 10 years ago
Blocking: | 12007 added |
---|
comment:10 by , 10 years ago
Just to state for others with the same issue the workaround:
- enter the boot-options by holding SHIFT wile booting
- choose "Use fail-safe video mode"
- boot into Haiku and open the Screen preferences
- change the video mode e.g. from 32bit to 16bit, apply, change back to 32bit, apply (you have to change something for the apply button to be clickable)
- reboot
Now you should be able to boot without using fail-safe video mode.
comment:11 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:12 by , 6 years ago
Milestone: | R1 → R1/beta2 |
---|
comment:14 by , 6 years ago
Can't check until intel_extreme driver is working for my hardware, see #14643.
comment:15 by , 5 years ago
Component: | Drivers/Graphics/intel_extreme → Drivers/Graphics/intel_extreme/ivybridge |
---|
comment:16 by , 5 years ago
Blocked By: | 14643 added |
---|
comment:17 by , 5 years ago
Component: | Drivers/Graphics/intel_extreme/ivybridge → Drivers/Graphics/intel_extreme/haswell |
---|
comment:18 by , 5 years ago
Milestone: | R1/beta2 → R1/beta3 |
---|
Move intel_extreme tickets where the original reporter is not responding to beta3. They can be moved back if we get some feedback, but otherwise, no progress will be made. So let's focus on people who keep their bugreports up to date.
comment:19 by , 4 years ago
Milestone: | R1/beta3 → R1 |
---|
No one is working on the intel driver at the moment so it seems no progress will be made on these issues for beta3. Remove them from the milestone so we can better see our status.
comment:20 by , 3 years ago
Blocking: | 17324 added |
---|
comment:22 by , 3 years ago
Indeed, this seems to be fixed. Thanks\\ I did encounter a "boot-to-blue-screen-with-mouse-pointer" and had to restart Desktop from TeamMonitor. When trying to get a syslog, it just would not reproduce...
comment:23 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Yeah I have also this boot-to-bluescreen every other boot on Qemu. Looks like a regression somehow.
comment:24 by , 3 years ago
It's probably another variant of #17365. That manifests either as a hang on rocket or a blue screen with mouse cursor depending on what applications are set to start on boot (i.e. first app_server connection.)
comment:25 by , 3 years ago
FWIW, I only got those blue screens when booting the newly installed, pristine nightly image. My old "production" installation that I use full time and gets updated about once a week (nightlies), never boots into a blue screen.
syslog