Latest working kernel version: - Earliest failing kernel version: Distribution: gentoo Hardware Environment: lenovo thinkpad r61 (1400x1050) Software Environment: grub boot loader Problem Description: screen goes black as soon as grub hands of to the kernel Steps to reproduce: boot with i915.modeset=1 Hi! if i enable on current git via i915.modeset=1 kernelmodesetting the screen stays blank and black. (it never worked as far as i know) The Computer starts up normal and i can shut him down / reboot flying blind. If i start gdm i can login, but textrendering is slow. mode is set to 1024x768. switching to console leaves the current X framebuffer-content untouched (no redraw) until i switch back to X. (xorg-server, xf86-video-intel, mesa, libdrm are all from current git (the master branches)) I'm on a lenovo thinkpad r61 without anything attached, besides power and network (native lvds resolution is 1400x1050). normally i work with my laptop in a dockingstation and textmode switched via bios to vga output. but normally if vga is disconnected text gets displayed on my lvds. attached are dmesg, lspci -v, and xorg log for kms and non-kms boot.
Created attachment 20061 [details] dmesg startup without kms enabled
Created attachment 20062 [details] dmesg startup -- kms enabled there is some 1400x1050 mentioned, but not set...
Created attachment 20063 [details] lspci -v output
Created attachment 20064 [details] normal xorg startup fyi
Created attachment 20065 [details] xorg startup with kms enabled this starts up in 1024x786 and xrandr --output LVDS1 --auto sets it back to 1400x1050, but the picture just gets pushed into the topleft-edge... not rescaled...
Do you have the framebuffer console driver builtin or loaded? If not, i915 won't paint anything on the screen and will leave your display off. Also without another graphics configuration to switch to, the X contents will be left alone by the kernel, so you won't see anything change (X probably won't draw to it much while VT switched), so this could be normal. The slowness you see with text rendering could be an UXA problem (it doesn't map pixmaps through the GTT in the KMS case).
ah yes. with framebuffer console driver, the console works. nice. thx. (xorg: exa has corruption issues, the uxa-text-rendering slowness with kms persists...) i'm back now at my dockingstation with attached vga output.. which brings me to the further questions: how is dualhead supported at the moment? because there are some issues, modesetting wise : it best works if i switch platformwise to the internal display while the laptop-firmware is in dos-mode (before grub hands off control). then kms sets my internal display nicely up and my vga is in clone-mode if my vga is firmware-wise the primary output, then the lvds is somehow funny white (in a way which makes me wonder if it is healthy to the hardware) and the vga gets the same mode set as the lvds before (which leaves the black borders, which i tolerated in clonemode... ) if x starts up, the graphics are unsharp until i xrandr --auto the vga1 (which clears up vga1, but doesnt scale it up, which seems like bad modesetting<->xorg interaction) xrandr on lvds1 doesn't work and gives errors... sorry for misusing this bugzilla to satisfy my curiosity and thx for your reply. and sorry if i don't express myself clearly or misuse vocabulary: i'm no mode-setting hacker and no native speaker
hi, i just tested i915.modeset=1 again with rc-8 + eanholt/intel-drm-next for my dualhead setup i amended the xorg.conf driver section to use the right monitor-sections (because of the rename LVDS -> LVDS1 and VGA -> VGA1 that wouldnt work anymore) that leaves no problems for me besides the last point: it seems the only real (persisting) problem in my bugreport was the slow rendering of text. this is with rxvt as virtual terminal. xterm, konsole and gnome-terminal all do not exhibit this slowness (5-10 secs to display dmesg) i've installed from current git: dri2proto inputproto libdrm libXcomposite libXdamage libXext libXfixes libXrandr mesa pixman randrproto xextproto xf86-input-evdev xf86-video-intel xorg-server What should I do to get rxvt back up to speed? (i assume, that there are other programms which exhibit the same problem... but haven't found anything) do you need more info? should we close this bugreport and open a new one?
Yeah, the rxvt slowness is probably not a kernel problem but an UXA problem of some kind. Please close this one out and file a new bug at bugs.freedesktop.org.
PEBCAK
see also http://bugs.freedesktop.org/show_bug.cgi?id=20666