Description: No xv when using uxa acceleration method. Expected result: xvinfo shows list of xv adapters. Expected result: xvinfo shows "no adaptors present". Source: xserver-xorg-video-intel-2.99.917+git20170309 I identified that the problem is in src/uxa/intel_video.c file intel_video_init function: if (!intel->force_fallback && scrn->bitsPerPixel >= 16 && INTEL_INFO(intel)->gen >= 030 && INTEL_INFO(intel)->gen < 0100) { texturedAdaptor = intel_uxa_video_setup_image_textured(screen); if (texturedAdaptor != NULL) { xf86DrvMsg(scrn->scrnIndex, X_INFO, "Set up textured video\n"); } else { xf86DrvMsg(scrn->scrnIndex, X_ERROR, "Failed to set up textured video\n"); } } In my case INTEL_INFO(intel)->gen==74 so I should get either "Set up textured video\n" or "Failed to set up textured video\n" message in Xorg log. But there is nothing in the log: [ 39864.856] (==) Depth 24 pixmap format is 32 bpp [ 39864.856] (II) intel(0): Allocated new frame buffer 5120x1800 stride 20480, tiled [ 39864.856] (II) UXA(0): Driver registered support for the following operations: [ 39864.856] (II) solid [ 39864.856] (II) copy [ 39864.856] (II) put_image [ 39864.856] (II) get_image [ 39864.856] (II) intel(0): [DRI2] Setup complete [ 39864.856] (II) intel(0): [DRI2] DRI driver: i965 [ 39864.856] (II) intel(0): [DRI2] VDPAU driver: va_gl [ 39864.856] (==) intel(0): Backing store enabled [ 39864.856] (==) intel(0): Silken mouse enabled [ 39864.856] (II) intel(0): Initializing HW Cursor [ 39864.856] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 39864.856] (==) intel(0): DPMS enabled [ 39864.856] (==) intel(0): Intel XvMC decoder enabled [ 39864.856] (WW) intel(0): Disabling Xv because no adaptors could be initialized. [ 39864.856] (II) intel(0): DRI2: Enabled [ 39864.856] (II) intel(0): DRI3: Enabled I even tried such condition with zero result: if (INTEL_INFO(intel)->gen >= 030 && INTEL_INFO(intel)->gen < 0100) { It started working only with the following condition: if (!intel->force_fallback && scrn->bitsPerPixel >= 16 && INTEL_INFO(intel)->gen >= 030) { I wonder why it happened, the only thing I think it can be some compiler optimizations which break the logic. Anyway after this fix everything works as expected: [ 16960.400] (==) Depth 24 pixmap format is 32 bpp [ 16960.400] (II) intel(0): Allocated new frame buffer 5120x1800 stride 20480, tiled [ 16960.400] (II) UXA(0): Driver registered support for the following operations: [ 16960.400] (II) solid [ 16960.400] (II) copy [ 16960.400] (II) put_image [ 16960.400] (II) get_image [ 16960.400] (II) intel(0): [DRI2] Setup complete [ 16960.400] (II) intel(0): [DRI2] DRI driver: i965 [ 16960.400] (II) intel(0): [DRI2] VDPAU driver: va_gl [ 16960.400] (==) intel(0): Backing store enabled [ 16960.400] (==) intel(0): Silken mouse enabled [ 16960.400] (II) intel(0): Initializing HW Cursor [ 16960.400] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 16960.400] (==) intel(0): DPMS enabled [ 16960.400] (==) intel(0): Intel XvMC decoder enabled [ 16960.400] (II) intel(0): Set up textured video [ 16960.400] (II) intel(0): [XvMC] xvmc_vld driver initialized. [ 16960.400] (II) intel(0): DRI2: Enabled [ 16960.400] (II) intel(0): DRI3: Enabled
g620 should be Sandybridge. Attach the full xorg.log.
Created attachment 130709 [details] Full Xorg.log Log is attached. Here is also lspci: 00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02) I have i7-7500u CPU which is Kaby Lake arch. And g620 is always referred to Kaby Lake like in https://www.notebookcheck.net/Intel-HD-Graphics-620.172256.0.html.
Ah, that's HD Graphics 620. (g620 is the cpu). UXA does not support Skylake+, it's just a fluke that you haven't hit one of the altered commands.
First thing is that users had significant glitches with sna and had to switch to uxa. Today I tried fresh Git sources and it seems that sna glitches had gone. But anyway this bug affects all GPUs, even pre-Skylake.
It should only affect Broadwell/Braswell, Skylake/Broxton/Kabylake and later since they are the ones for which the video render hasn't been plugged in for uxa.
I had to use uxa on my Kabylake (and on Skylake on my second laptop) as sna was just awful and unusable for a long time. So it affected new chipsets as well. I hope that with resent sna changes it will affect only old chipsets that had to use uxa. Anyway, I think it won't prevent fixing this bug :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/140.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.