[PATCH] xorg/driver/x86-video-intel: Avoid flicker on transition from the fb console to X
This patch avoids flicker as the Linux boot fbcon gives way to X by
taking an exact pixmap represenation of the fb console and rendering it
to the X display before transitioning.
---
The original patch seems to have been by Kristian Høgsberg, but every
distro has a slight variation in their build package for the intel
driver. It's time to get it upstream to avoid us all forward porting
copies (and possibly getting it wrong).
James
Index: xf86-video-intel-2.14.903/src/intel.h
===
--- xf86-video-intel-2.14.903.orig/src/intel.h
+++ xf86-video-intel-2.14.903/src/intel.h
@@ -462,6 +462,7 @@ extern void intel_mode_fini(intel_screen
extern int intel_get_pipe_from_crtc_id(drm_intel_bufmgr *bufmgr, xf86CrtcPtr
crtc);
extern int intel_crtc_id(xf86CrtcPtr crtc);
extern int intel_output_dpms_status(xf86OutputPtr output);
+extern void intel_copy_fb(ScrnInfoPtr pScrn);
enum DRI2FrameEventType {
DRI2_SWAP,
Index: xf86-video-intel-2.14.903/src/intel_display.c
===
--- xf86-video-intel-2.14.903.orig/src/intel_display.c
+++ xf86-video-intel-2.14.903/src/intel_display.c
@@ -30,6 +30,7 @@
#endif
#include sys/types.h
+#include sys/ioctl.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
@@ -1426,6 +1427,108 @@ fail:
return FALSE;
}
+static PixmapPtr
+intel_create_pixmap_for_fbcon(ScrnInfoPtr pScrn)
+{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
+ ScreenPtr pScreen = screenInfo.screens[pScrn-scrnIndex];
+ drmModeFBPtr fbcon = NULL;
+ PixmapPtr pixmap = NULL;
+ struct drm_gem_flink flink;
+ drm_intel_bo *bo;
+
+ struct intel_crtc *intel_crtc = xf86_config-crtc[0]-driver_private;
+ struct intel_mode *intel_mode = intel_crtc-mode;
+ intel_screen_private *intel = intel_get_screen_private(pScrn);
+ int i;
+
+ for (i = 0; i intel_mode-mode_res-count_crtcs; i++) {
+ intel_crtc = xf86_config-crtc[i]-driver_private;
+
+ fbcon = drmModeGetFB(intel_mode-fd, intel_crtc-mode_crtc-buffer_id);
+ if (fbcon != NULL) break;
+ }
+ if (fbcon == NULL) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+ Couldn't find an fbcon\n.);
+ return NULL;
+ }
+ flink.handle = fbcon-handle;
+ if (ioctl(intel_mode-fd, DRM_IOCTL_GEM_FLINK, flink) 0) {
+xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+ Couldn't flink fbcon handle\n);
+return NULL;
+ }
+ bo = drm_intel_bo_gem_create_from_name(intel-bufmgr,
+fbcon, flink.name);
+
+ if (bo == NULL) {
+xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+ Couldn't allocate bo for fbcon handle\n);
+return NULL;
+ }
+
+ pixmap = GetScratchPixmapHeader(pScreen,
+ fbcon-width, fbcon-height,
+ fbcon-depth, fbcon-bpp,
+ fbcon-pitch, NULL);
+ if (pixmap == NULL) {
+xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+ Couldn't allocate pixmap fbcon contents\n);
+return NULL;
+ }
+
+ intel_set_pixmap_bo(pixmap, bo);
+ drm_intel_bo_unreference(bo);
+ drmModeFreeFB(fbcon);
+
+ return pixmap;
+}
+
+void intel_copy_fb(ScrnInfoPtr pScrn)
+{
+ ScreenPtr pScreen = screenInfo.screens[pScrn-scrnIndex];
+ intel_screen_private *intel = intel_get_screen_private(pScrn);
+ PixmapPtr src, dst;
+ unsigned int pitch = pScrn-displayWidth * intel-cpp;
+ int savePMSize;
+ int pixmap_size;
+
+ /* Ugly: this runs before CreateScratchPixmap() which normally calculates
+ this number :(
+ */
+ pixmap_size = sizeof(PixmapRec) + dixPrivatesSize(PRIVATE_PIXMAP);
+ savePMSize = pScreen-totalPixmapSize;
+ pScreen-totalPixmapSize = BitmapBytePad(pixmap_size * 8);
+
+ src = intel_create_pixmap_for_fbcon(pScrn);
+ if (src == NULL) {
+xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+ Couldn't create pixmap for fbcon\n);
+pScreen-totalPixmapSize = savePMSize;
+return;
+ }
+
+ /* We dont have a screen Pixmap yet */
+ dst = GetScratchPixmapHeader(pScreen,
+ pScrn-virtualX, pScrn-virtualY,
+ pScrn-depth, pScrn-bitsPerPixel,
+ pitch,
+ NULL);
+ pScreen-totalPixmapSize = savePMSize;
+ intel_set_pixmap_bo(dst,intel-front_buffer);
+ intel-uxa_driver-prepare_copy(src, dst, -1, -1, GXcopy, FB_ALLONES);
+
+ intel-uxa_driver-copy(dst, 0, 0, 0, 0,
+ pScrn-virtualX, pScrn-virtualY);
+ intel-uxa_driver-done_copy(dst);
+
+ intel_batch_submit(pScrn);
+
+ (*pScreen-DestroyPixmap)(src);
+ (*pScreen-DestroyPixmap)(dst);
+}
+
Bool
intel_do_pageflip(intel_screen_private *intel,
dri_bo *new_front,
@@ -1573,6 +1676,8 @@ Bool intel_mode_pre_init(ScrnInfoPtr scr
unsigned int i;
int has_flipping;
+ scrn-canDoBGNoneRoot = TRUE;
+
mode =
[BUG] xrandr/desktop autoconfiguration problem with Intel chip
The chip in question is this one: 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Hewlett-Packard Company Device 3056 Flags: bus master, fast devsel, latency 0 Memory at e820 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 The default drm based xrandr gives this as the screen size: Screen 0: minimum 320 x 200, current 1366 x 768, maximum 4096 x 4096 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 224mm x 126mm 1366x768 60.0*+ 1024x768 60.0 800x60060.3 56.2 640x48059.9 VGA1 disconnected (normal left inverted right x axis y axis) However, when I plug in a standard 1024x768 projector, it gets set up (using the standard gnome hotplug) to the right of my current display (giving an x dimension of 2390) and the whole of the LVDS display gets a dark grey shadow. If I use xrandr to redo the tiling so LVDS1 is above VGA1 (giving a max y dimension of 1536) everything is fine. I think this indicates that although my graphics chip seems to identify as GEN 3, it has trouble with display dimensions 2048. I didn't notice this with previous versions of opensuse because the xrandr max for the display was 2048x2048 (and thus hotplug fails, but that's a gnome bug). James ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: i915 backlight failure on resume with 2.6.27
On Tue, 2008-12-09 at 13:38 +, Sergio Monteiro Basto wrote: OK , at least on Fedora 10, we have on updates. A new kernel with message: Additional DRM/modesetting fixes for i915 and radeon drivers. A new release of Mesa and a new release of drv-intel (which in fedora still called i810, may be its time to change the name of drive for Intel no?) Well, I filed a bug in the redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=474376 Just in case anyone over there was interested; although it looks like a simple error in backporting the i915 drm to me since the kernel.org kernel works just fine. I assume it will correct itself when FC9 moves over to a 2.6.28 kernel. James ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
On Tue, 2008-12-02 at 13:08 +, Sergio Monteiro Basto wrote:
On Mon, 2008-12-01 at 11:42 -0600, James Bottomley wrote:
You probably remember the system, it's my fujitsu P7120 lifebook with
the funny backlight wiring.
Previously, suspend/resume was made to work by saving the PCI state
including the legacy backlight register setting (and worked just fine
when invoked with a hal quirk).
On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and
relies on the i915 kernel driver. This was perfectly fine, except that
the backlight was now being restored to full brightness on resume rather
than the setting on resume. The other annoyance was that VT consoles
were now lost on resume (switching to them produces a black screen,
although switching back to vt7 where X is running is fine).
As of the 2.6.27 fedora kernels, the backlight is now off on resume,
which is even more annoying. It can be turned on by doing a VT switch,
although all the console VTs are still blank, so there looks to be some
bug in the i915 driver that crept in between 2.6.26 and 2.6.27.
Hum as quick answer , kernel fedora 2.6.27 have change _DOS thing.
So may be that is the problem.
The fedora patch is talked about on lkml
http://lkml.org/lkml/2008/11/10/233
Actually, they haven't. I'm running 2.6.27.5-41.fc9.i686 and if I look
in the kernel SRPM for that kernel (by building it) the relevant area of
drivers/acpi/video.c is
/* acpi_video interface */
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0, 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0, 1);
}
So nothing's changed in that area since 2.6.26.
It could still be a disagreement between ACPI, BIOS and the driver over
who turns on the backlight, but the loss of the text console strongly
suggests that something is slightly wrong with the VGA modes.
About this _DOS , I reported this problem a long time ago, which now
is on http://bugzilla.kernel.org/show_bug.cgi?id=6001
James
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
On Mon, 2008-12-01 at 11:42 -0600, James Bottomley wrote: You probably remember the system, it's my fujitsu P7120 lifebook with the funny backlight wiring. Previously, suspend/resume was made to work by saving the PCI state including the legacy backlight register setting (and worked just fine when invoked with a hal quirk). On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and relies on the i915 kernel driver. This was perfectly fine, except that the backlight was now being restored to full brightness on resume rather than the setting on resume. The other annoyance was that VT consoles were now lost on resume (switching to them produces a black screen, although switching back to vt7 where X is running is fine). As of the 2.6.27 fedora kernels, the backlight is now off on resume, which is even more annoying. It can be turned on by doing a VT switch, although all the console VTs are still blank, so there looks to be some bug in the i915 driver that crept in between 2.6.26 and 2.6.27. Jesse asked for the reg dump from xf86-video-intel-2.4.3, so here it is: (II): DumpRegsBegin (II):VCLK_DIVISOR_VGA0: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II):VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6) (II):VCLK_POST_DIV: 0x00800080 (vga0 p1 = 2, p2 = 4, vga1 p1 = 2, p2 = 2) (II):DPLL_TEST: 0x00010001 () (II): CACHE_MODE_0: 0x6820 (II): D_STATE: 0x (II):DSPCLK_GATE_D: 0x1000 (clock gates disabled: DPLUNIT) (II): RENCLK_GATE_D1: 0x (II): RENCLK_GATE_D2: 0x (II):SDVOB: 0x0030 (disabled, pipe A, stall disabled, not detected, SDVO mult 1) (II):SDVOC: 0x0030 (disabled, pipe A, stall disabled, not detected, SDVO mult 1) (II): SDVOUDI: 0x00ff (II): DSPARB: 0x1d9c (II): DSPFW1: 0x (II): DSPFW2: 0x (II): DSPFW3: 0x (II): ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) (II): LVDS: 0xc0200300 (enabled, pipe B, 18 bit, 1 channel) (II): DVOA: 0x (disabled, pipe A, no stall, -hsync, -vsync) (II): DVOB: 0x0030 (disabled, pipe A, no stall, -hsync, -vsync) (II): DVOC: 0x0030 (disabled, pipe A, no stall, -hsync, -vsync) (II): DVOA_SRCDIM: 0x (II): DVOB_SRCDIM: 0x (II): DVOC_SRCDIM: 0x (II): PP_CONTROL: 0x0001 (power target: on) (II):PP_STATUS: 0xc008 (on, ready, sequencing idle) (II): PFIT_CONTROL: 0x0008 (II): PFIT_PGM_RATIOS: 0x (II): PORT_HOTPLUG_EN: 0x (II):PORT_HOTPLUG_STAT: 0x (II): DSPACNTR: 0xd900 (enabled, pipe B) (II): DSPASTRIDE: 0x2000 (8192 bytes) (II): DSPAPOS: 0x (0, 0) (II): DSPASIZE: 0x02ff04ff (1280, 768) (II): DSPABASE: 0x0100 (II): DSPASURF: 0x (II): DSPATILEOFF: 0x (II):PIPEACONF: 0x (disabled, single-wide) (II): PIPEASRC: 0x027f01df (640, 480) (II):PIPEASTAT: 0x (status:) (II): FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): DPLL_A: 0x0480 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 8, p2 = 10) (II):DPLL_A_MD: 0x (II): HTOTAL_A: 0x031f027f (640 active, 800 total) (II): HBLANK_A: 0x03170287 (648 start, 792 end) (II): HSYNC_A: 0x02ef028f (656 start, 752 end) (II): VTOTAL_A: 0x020c01df (480 active, 525 total) (II): VBLANK_A: 0x020401e7 (488 start, 517 end) (II): VSYNC_A: 0x01eb01e9 (490 start, 492 end) (II):BCLRPAT_A: 0x (II): VSYNCSHIFT_A: 0x (II): DSPBCNTR: 0x4900 (disabled, pipe B) (II): DSPBSTRIDE: 0x0400 (1024 bytes) (II): DSPBPOS: 0x (0, 0) (II): DSPBSIZE: 0x018f02cf (720, 400) (II): DSPBBASE: 0x (II): DSPBSURF: 0x (II): DSPBTILEOFF: 0x (II):PIPEBCONF: 0x8000 (enabled, single-wide) (II): PIPEBSRC: 0x04ff02ff (1280, 768) (II):PIPEBSTAT: 0x8242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS) (II): FPB0: 0x00021006 (n = 2, m1 = 16, m2 = 6) (II): FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): DPLL_B: 0x9802 (enabled, non-dvo, default clock, LVDS mode, p1 = 2, p2 = 14) (II):DPLL_B_MD: 0x (II): HTOTAL_B: 0x069704ff (1280 active, 1688 total) (II): HBLANK_B: 0x069704ff (1280 start, 1688 end) (II
i915 backlight failure on resume with 2.6.27
You probably remember the system, it's my fujitsu P7120 lifebook with the funny backlight wiring. Previously, suspend/resume was made to work by saving the PCI state including the legacy backlight register setting (and worked just fine when invoked with a hal quirk). On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and relies on the i915 kernel driver. This was perfectly fine, except that the backlight was now being restored to full brightness on resume rather than the setting on resume. The other annoyance was that VT consoles were now lost on resume (switching to them produces a black screen, although switching back to vt7 where X is running is fine). As of the 2.6.27 fedora kernels, the backlight is now off on resume, which is even more annoying. It can be turned on by doing a VT switch, although all the console VTs are still blank, so there looks to be some bug in the i915 driver that crept in between 2.6.26 and 2.6.27. James ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
