Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window
On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote: > On Thu, 23 Jun 2016, Steven Newbury wrote: > > [ Unknown signature status ] > > On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote: > > > On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: > > > > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > > > > > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > > > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley > > > > > > wrote: > > > > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > > > > > > > > > I guess we'll need the bisect on this one to make > > > > > > > > > progress. > > > > > > > > > > > > > > > > Sigh, I was afraid that might be the next step. > > > > > > > > > > > > > > OK, I have a curious data point. I assumed the problem > > > > > > > would > > > > > > > be > > > > > > > somewhere in the drm update, so I started bisecting that > > > > > > > at > > > > > > > the > > > > > > > top. > > > > > > > However, the top most commit: > > > > > > > > > > > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c > > > > > > > Merge: 1f40c49 a39ed68 > > > > > > > Author: Linus Torvalds > > > > > > > Date: Mon May 23 11:48:48 2016 -0700 > > > > > > > > > > > > > > Merge branch 'drm-next' of > > > > > > > git://people.freedesktop.org/~airlied/linux > > > > > > > > > > > > > > Isn't actually bad. There's no flicker here, so whatever > > > > > > > caused > > > > > > > the > > > > > > > problem came from some update after this. > > > > > > > > > > > > There was a fixes pull after this. Might be worth it to > > > > > > restrict > > > > > > to > > > > > > just > > > > > > the i915 changes, which are just > > > > > > 5b4fd5bb1230cd037..157d2c7fad0863222 > > > > > > > > > > > > Looking at those nothing seems to stick out which might > > > > > > explain > > > > > > what's > > > > > > happening for you. > > > > > > > > OK, so just on the firmware, the system seems less flickery > > > > with > > > > the > > > > new 1.4.3 UEFI, so I'm starting to think it is a Skylake > > > > errata > > > > issue. The flicker isn't gone for good, but seems to be > > > > reboot > > > > dependent (it's there in some boots, but gone on a reboot). > > > > > > > > > This should be easy enough to try before bisecting: > > > > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042 > > > > > -1-g > > > > > it > > > > > -s > > > > > end-email-mika.kah...@intel.com > > > > > > > > Applying this didn't seem to make a difference: still there on > > > > some > > > > and gone on other reboots. > > > > > > OK, my candidate bad commit is this one: > > > > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee > > > Author: Ville Syrjälä > > > Date: Mon Apr 11 10:23:51 2016 +0300 > > > > > > drm/i915: Get panel_type from OpRegion panel details > > > > > > After being more careful about waiting to identify flicker, this > > > one > > > seems to be the one the bisect finds. I'm now running v4.7-rc3 > > > with > > > this one reverted and am currently seeing no flicker > > > problems. It > > > is, > > > however, early days because the flicker can hide for long > > > periods, so > > > I > > > 'll wait until Monday evening and a few reboots before declaring > > > victory. > > > > > > > > I'm seeing this on my IvyBridge. I'll try reverting the commit > > here > > too, to see if it's the same issue. > > IvyBridge doesn't have low vswing for eDP. If reverting helps, it's a > different failure mode. > It must be something else then. Actually, in my case linus/master is okay. I saw the subject and though it must be the same issue. I'm seeing it with drm-intel nightly/next branches. Shall I try to bisect it? Symptoms are similar, although I would describe it more like flashes of a different buffer across parts of the screen. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window
On Sun, 2016-06-19 at 14:53 -0700, James Bottomley wrote: > On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote: > > On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > > > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley > > > > wrote: > > > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: > > > > > > > I guess we'll need the bisect on this one to make > > > > > > > progress. > > > > > > > > > > > > Sigh, I was afraid that might be the next step. > > > > > > > > > > OK, I have a curious data point. I assumed the problem would > > > > > be > > > > > somewhere in the drm update, so I started bisecting that at > > > > > the > > > > > top. > > > > > However, the top most commit: > > > > > > > > > > commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c > > > > > Merge: 1f40c49 a39ed68 > > > > > Author: Linus Torvalds > > > > > Date: Mon May 23 11:48:48 2016 -0700 > > > > > > > > > > Merge branch 'drm-next' of > > > > > git://people.freedesktop.org/~airlied/linux > > > > > > > > > > Isn't actually bad. There's no flicker here, so whatever > > > > > caused > > > > > the > > > > > problem came from some update after this. > > > > > > > > There was a fixes pull after this. Might be worth it to > > > > restrict > > > > to > > > > just > > > > the i915 changes, which are just > > > > 5b4fd5bb1230cd037..157d2c7fad0863222 > > > > > > > > Looking at those nothing seems to stick out which might explain > > > > what's > > > > happening for you. > > > > OK, so just on the firmware, the system seems less flickery with > > the > > new 1.4.3 UEFI, so I'm starting to think it is a Skylake errata > > issue. The flicker isn't gone for good, but seems to be reboot > > dependent (it's there in some boots, but gone on a reboot). > > > > > This should be easy enough to try before bisecting: > > > http://patchwork.freedesktop.org/patch/msgid/1466162081-12042-1-g > > > it > > > -s > > > end-email-mika.kah...@intel.com > > > > Applying this didn't seem to make a difference: still there on > > some > > and gone on other reboots. > > OK, my candidate bad commit is this one: > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee > Author: Ville Syrjälä > Date: Mon Apr 11 10:23:51 2016 +0300 > > drm/i915: Get panel_type from OpRegion panel details > > After being more careful about waiting to identify flicker, this one > seems to be the one the bisect finds. I'm now running v4.7-rc3 with > this one reverted and am currently seeing no flicker problems. It > is, > however, early days because the flicker can hide for long periods, so > I > 'll wait until Monday evening and a few reboots before declaring > victory. > > I'm seeing this on my IvyBridge. I'll try reverting the commit here too, to see if it's the same issue. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window
On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote: > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote: > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote: > > > On Thu, 23 Jun 2016, Steven Newbury > > > wrote: > > > > I'm seeing this on my IvyBridge. I'll try reverting the commit > > > > here > > > > too, to see if it's the same issue. > > > > > > IvyBridge doesn't have low vswing for eDP. If reverting helps, > > > it's a > > > different failure mode. > > > > > It must be something else then. Actually, in my case linus/master > > is > > okay. I saw the subject and though it must be the same issue. I'm > > seeing it with drm-intel nightly/next branches. Shall I try to > > bisect > > it? Symptoms are similar, although I would describe it more like > > flashes of a different buffer across parts of the screen. > > Try reverting ee042aa40b66d18d465206845b0752c6a617ba3f instead. > -Chris > Yes, thanks, that "fixed" it. So atomic commits not working properly on IVB? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.11-rc2 (acpi backlight, revert)
On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote: > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote: > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote: > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki wrote: > > > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and > > > > efaa14c? > > > > > > Yes, but let's wait a while. Not because I think we'll fix the problem > > > (hey, miracles might happen), but because I think it would be useful > > > to couple the reverts with information about the particular machines > > > that broke (and the people who reported it). So that when we > > > inevitably try again, we can perhaps get some testing effort with > > > those machines/people. > > > > > > It doesn't seem to be a show-stopped for a large number of people, so > > > there's no huge hurry. I'd suggest doing the revert just in time for > > > rc3, but waiting until then to gather info about people who see > > > breakage. > > > > > > Sound like a plan? > > > > Yes, it does. > > OK, time to revert I guess. > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch > fixes the backlight for you. > > Aaron, please double check if acpi_video_backlight_quirks() will still work as > needed. > > Thanks, > Rafael > > > --- > From: Rafael J. Wysocki > Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects > Windows 8" > > We attempted to address a regression introduced by commit a57f7f9 > (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which > ACPI video backlight support doesn't work on a number of systems, > because the relevant AML methods in the ACPI tables in their BIOSes > become useless after the BIOS has been told that the OS is compatible > with Windows 8. That problem is tracked by the bug entry at: > > https://bugzilla.kernel.org/show_bug.cgi?id=51231 > > Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware > expects Windows 8) introduced for this purpose essentially prevented > the ACPI backlight support from being used if the BIOS had been told > that the OS was compatible with Windows 8 and the i915 driver was > loaded, in which case the backlight would always be handled by i915. > Unfortunately, however, that turned out to cause problems with > backlight to appear on multiple systems with symptoms indicating that > i915 was unable to control the backlight on those systems as > expected. > > For this reason, revert commit 8c5bd7a, but leave the function > acpi_video_backlight_quirks() introduced by it, because another > commit on top of it uses that function. > Works fine for me. Tested-by: Steven Newbury By the way, I'm willing to test any i915 backlight patches if it helps. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote: > On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle wrote: > > Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]: > >> Hm, if this is really a regression between 3.13 and 3.14-rc1 then I > >> don't see any quick candidates - relevant functions in intel-gtt.c > >> seem unchanged. > >> > >> So probably a bisect is what we need here. Note that this could also > >> be due to resource handling changes in the driver/pci core, so you > >> can't restrict the bisect really. > > > > The last bisect on this machine took over 20 builds to pinpoint the > > offending commit. So that's bad news ... > > Somehow we can't allocate the flush page resource any more, but I > don't have any idea what. There's nothing occupying the old spot (the > usual reason why resource management goes boom), so dunno why this > doesn't work any more. I think bisecting is the most fruitful avenue > here. > -Daniel > > > > > >> But before going down this route it > >> would be worth to check out the resource allocations of both kernels. > >> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1 > > > > The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is: > > --- iomem-3.13.22014-02-08 21:14:30.214030591 +0100 > > +++ iomem-3.14-rc1 2014-02-08 21:07:22.041189158 +0100 > > @@ -11,16 +11,13 @@ > >000e-000e : Extension ROM > >000f-000f : System ROM > > 0010-7f6d : System RAM > > - 0040-009af63a : Kernel code > > - 009af63b-00c932ff : Kernel data > > - 00d4f000-00e4dfff : Kernel bss > > + 0040-009c57bf : Kernel code > > + 009c57c0-00cb6aff : Kernel data > > + 00d78000-00e74fff : Kernel bss > > 7f6e-7f6f4fff : ACPI Tables > > 7f6f5000-7f6f : ACPI Non-volatile Storage > > 7f70-7fff : reserved > >7f80-7fff : Graphics Stolen Memory > > -8000-801f : PCI Bus :02 > > -8020-8027 : :00:02.1 > > -8028-80280fff : Intel Flush Page > > a000-a003 : :00:02.0 > > a004-a00403ff : :00:1d.7 > >a004-a00403ff : ehci_hcd > > > > /proc/iomem for v3.13.2: > > -0fff : reserved > > 1000-0009efff : System RAM > > 0009f000-0009 : reserved > > 000a-000b : Video RAM area > > 000c-000c7fff : Video ROM > > 000c8000-000cbfff : pnp 00:00 > > 000cf800-000d3fff : reserved > > 000cf800-000d0dff : Adapter ROM > > 000d1000-000d1fff : Adapter ROM > > 000dc000-000f : reserved > > 000e-000e : Extension ROM > > 000f-000f : System ROM > > 0010-7f6d : System RAM > > 0040-009af63a : Kernel code > > 009af63b-00c932ff : Kernel data > > 00d4f000-00e4dfff : Kernel bss > > 7f6e-7f6f4fff : ACPI Tables > > 7f6f5000-7f6f : ACPI Non-volatile Storage > > 7f70-7fff : reserved > > 7f80-7fff : Graphics Stolen Memory > > 8000-801f : PCI Bus :02 > > 8020-8027 : :00:02.1 > > 8028-80280fff : Intel Flush Page > > a000-a003 : :00:02.0 > > a004-a00403ff : :00:1d.7 > > a004-a00403ff : ehci_hcd > > a0040400-a00404ff : :00:1e.2 > > a0040400-a00404ff : Intel ICH6 > > a0040800-a00409ff : :00:1e.2 > > a0040800-a00409ff : Intel ICH6 > > a008-a00f : :00:02.0 > > a010-a01f : PCI Bus :02 > > a010-a010 : :02:00.0 > > a010-a010 : tg3 > > a020-afff : PCI Bus :04 > > a020-a0200fff : :04:00.0 > > a020-a0200fff : yenta_socket > > a0201000-a02010ff : :04:00.1 > > a0201000-a02010ff : mmc0 > > a0202000-a0202fff : :04:02.0 > > a0202000-a0202fff : ipw2200 > > a400-a7ff : PCI CardBus :05 > > c000-cfff : :00:02.0 > > d000-d7ff : PCI Bus :04 > > d000-d3ff : PCI CardBus :05 > > e000-efff : PCI MMCONFIG [bus 00-ff] > > e000-efff : reserved > > e000-efff : pnp 00:01 > > f0008000-f000bfff : reserved > > f0008000-f000bfff : pnp 00:01 > > f000b410-f000b414 : iTCO_wdt > > f000b410-f000b414 : iTCO_wdt > > fec0-fec0 : reserved > > fec0-fec003ff : IOAPIC 0 > > fed14000-fed19fff : reserved > > fed14000-fed17fff : pnp 00:01 > > fed18000-fed18fff : pnp 00:01 > > fed19000-fed19fff : pnp 00:01 > > fed2-fed8 : reserved > > fee0-fee00fff : Local APIC > > fee0-fee00fff : reserved > > ff00- : reserved > > > > /proc/iomem for v3.14-rc1: > > -0fff : reserved > > 1000-0009efff : System RAM > > 0009f000-0009 : reserved > > 000a-000b : Video RAM area > > 000c-000c7fff : Video ROM > > 000c8000-000cbfff : pnp 00:00 > > 000cf800-000d3fff : reserved > > 000cf800-000d0dff : Adapter ROM > > 000d1000-000d1fff : Adapter ROM > > 000dc000-000f : reserved > > 000e-000e : Extension ROM > > 000f-000f : System ROM > > 0010-7f6d : System RAM > > 0040-009c57bf : Kernel code >
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote: > On Sun, 2014-02-09 at 13:15 +0000, Steven Newbury wrote: > > PCI resource allocation is undergoing some changes at the moment, it's > > definitely a bug if the Flush Page isn't getting allocated. I'm looking > > forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in > > mainline, it will provide much better resource allocation in the 32 bit > > PCI address space, and prevent problems like this from cropping up. > > > > See Yinghai Lu's for-pci-res-alloc branch. > > > > I've been carrying the changes in my local tree, but right now the > > upstream PCI changes are quite extensive. He's planning on rebasing the > > branch soon. > > Does this mean I might be better of not bisecting this just yet? Or are > these changes targeted at v3.15 (or later)? > > > Paul Bolle > It's an aside really for now. The bug has probably been introduced by the recent pci allocation changes so it should be easier for you to bisect, hopefully. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Help to enable Iris Pro on Retina MBP 11.3
On Wed, 2014-01-08 at 11:12 +0200, Jani Nikula wrote: > On Tue, 07 Jan 2014, "Lu, Ran" wrote: > > Hi Jani, > > > > As a matter of fact, I tried kernel from 3.9 to 3.13-rc6, all of them > > cannot > > read the pci information from 0:2.0, and lspci do not have Iris Pro as a > > video > > controller. I put in the attachment dmesg output from 3.12.6, I added some > > printk to show the results from pci_bus_read_dev_vendor_id, otherwise it is > > a > > vanilla kernel. I do not think I get any extra information by adding > > drm.debug=0xe because the pci device is never registered properly, but it > > was > > there anyway.The weird thing is grub can read pci device fine, I took a > > picture > > since I do not know how to save outputs in grub console. I did some test > > with > > another laptop with a working HD 4600. It seems even if I use setpci -s > > 0:2.0 > > 4.b=0 to disable the device, it is still responsive to further setpci and I > > can bring it back by setting 4.b=7. Now it does not look like the video > > card > > is disable. I guess maybe something wrong in the ACPI table triggered the > > kernel to read the wrong place. But still strange it only missed that > > particular bus. In case you are interested, I also put the dsdt table in > > the > > attachment, I can provide other tables if they are important. > > I don't have much clues here. Are there any bios settings you could > tweak? Did you try without the nvidia driver loaded? > > BR, > Jani. > > Might it be unable to allocate enough PCI address or it gets allocated above 4G? There are patches queued up for pci-next (plus a few in my tree for i915; I need to get back to these) to get PCI address space above 4G working. Probably unrelated... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Pineview + libva
I'm building a HD network media player device and thought VAAPI was supposed to be supported on Pineview, am I wrong? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Pineview + libva
On Tue, 2011-03-22 at 14:52 +, Steven Newbury wrote: > I'm building a HD network media player device and thought VAAPI was supposed > to be > supported on Pineview, am I wrong? To answer my own question somewhat, from the list here: http://en.wikipedia.org/wiki/Intel_GMA It's clear the Pineview doesn't support hw VC-1 or AVC, but does support full MPEG2, but I guess, given the utility of MPEG2 hw accel vs h.264 there isn't too much interest in getting that working. I'll just have to hope there's enough performance from the CPU to cope with 720p material... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Pineview + libva
Missed CC to list (forwarded) - Original message - From Steven Newbury Sent Thu, 24 Mar 2011, 12:07:06 GMT To Sander Jansen Subject Re: [Intel-gfx] Pineview + libva > - Original message - > > On Tue, Mar 22, 2011 at 12:29 PM, Steven Newbury > > wrote: > > > On Tue, 2011-03-22 at 14:52 +, Steven Newbury wrote: > > > > I'm building a HD network media player device and thought VAAPI was > > > > supposed to be supported on Pineview, am I wrong? > > > > > > To answer my own question somewhat, from the list here: > > > http://en.wikipedia.org/wiki/Intel_GMA > > > > > > It's clear the Pineview doesn't support hw VC-1 or AVC, but does > > > support full MPEG2, but I guess, given the utility of MPEG2 hw accel > > > vs h.264 there isn't too much interest in getting that working. > > > > > > I'll just have to hope there's enough performance from the CPU to cope > > > with 720p material... > > > > I believe libva mostly supports gen4 and up. Pineview is supposed to > > be gen3. Perhaps XVMC may still work for it though. > I'm using MythTV, AFAIK they've dropped XvMC in favour of VAAPI and VDPAU. > > > In general don't buy hardware unless you know the driver supports your > > desired features. I should have listened to myself when I got a G45 > > and had the hope the h264 decoding support wouldn't take too long... > > Always good advise! In my case h.264 would have been really nice to have, but > hw > MPEG2 is actually very useful for MythTV, and I can always transcode HD > content > if necessary. > > What would be needed to get libva supporting the gen3 MPEG2 accelerator > functionality, is there much difference between gen3 and gen4 in that regard? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] YCbCr colourspace output
I'm connecting a D525 (Pineview) based system to an older "HD" (1366x768) Phillips TV. I has a DVI connector for HD input, but whether I connect it using the VGA->DVI or HDMI->DVI the TV detects the incomming signal as from a PC and selects a "XGA" mode, limiting the screen format to aspects and resolutions it expects a PC to use; like 640x480, 800x600, 1024x768 4:3/16:10 @60Hz (always with black borders), even though the TV officially supports HDTV 720p,1080i 50/60Hz etc.. I suspect the issue lies in the assumption that HDTV equipment would have a YCbCr colourspace. Now my question is, since I can't really modify the TV firmware, is it possible to add YCbCr output to the driver, assuming the chip supports it? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
- Original message - > I'm connecting a D525 (Pineview) based system to an older "HD" > (1366x768) Phillips TV. I has a DVI connector for HD input, but whether > I connect it using the VGA->DVI or HDMI->DVI the TV detects the > incomming signal as from a PC and selects a "XGA" mode, limiting the > screen format to aspects and resolutions it expects a PC to use; like > 640x480, 800x600, 1024x768 4:3/16:10 @60Hz (always with black borders), > even though the TV officially supports HDTV 720p,1080i 50/60Hz etc.. I > suspect the issue lies in the assumption that HDTV equipment would have > a YCbCr colourspace. > > Now my question is, since I can't really modify the TV firmware, is it > possible to add YCbCr output to the driver, assuming the chip supports > it? Okay, it's even weirder than I thought! Further testing has shown that with an analogue RGB input the frame always has a left/right borders (making it 16:10 when in "wide screen") and are restricted to 640x480, 800x600 and 1024x768, whilst the DVI-D input seems to be more resonable, except the BIOS on my board insists on configuring the HDMI port as an LVDS with BIOS configured mode timings. This wouldn't be too bad except the fixed mode in the BIOS for the native panel size (1366x768) gives a mode shifted significantly to the left (off the screen) and while the 1280x720 fits fine, the TV does a really awful job of scaling! I'm thinking this board must have an LVDS->HDMI converter so it wouldn't be suprising the driver treats it this way, even so it would be really handy to have an override to allow mode setting to adjust the apparent panel mode and so present such hardware in a useful fasion to userspace. Am I missing something, or does KMS only accept the BIOS provided panel timings? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
- Original message - > > > Am I missing something, or does KMS only accept the BIOS provided > > panel timings? > > There is a patch pending about setting LVDS parameters by hand if no or > incorrect display data is present. But the controlling options are still > being discussed as I understand it. > I just found the earlier NAK'd patch to dri-devel, having a lvds_native_mode parameter would help a lot, even better in this case would be a quirk to make the LVDS timings reprogrammable (appear as an HDMI connector) since it's actually _is_ wired to a HDMI connector! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Wed, 2011-02-09 at 15:01 +, Chris Wilson wrote: > > The LVDS code ignores any connector for which it cannot find a fixed > > mode (through an EDID, vBIOS tables or the current active mode). Some > > platforms may include an LVDS header on the board and this may then be > > partnered with a panel without an EDID. This results in us ignoring the > > connector and not lighting up the panel. > > Yeah not like this. > > you want to make the command line the *last* option we use, the final > fallback. LVDS panels have EDID and VBT hardcoded modes for a good > reason, they don't work with other modes that well. You always want to > use a scaler on the LVDS panel to do modes not the native mode. So if I > have a VBT or EDID and you set video= I should get a scaled mode, not > garbage. > > So what I suspect you really want is to leave video= alone or enhance it > somehow, or maybe add i915.lvds_native_mode= parameter. Hi Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
Sorry, about the empty reply. - Original message - > On Wed, 2011-02-09 at 15:01 +, Chris Wilson wrote: > > The LVDS code ignores any connector for which it cannot find a fixed > > mode (through an EDID, vBIOS tables or the current active mode). Some > > platforms may include an LVDS header on the board and this may then be > > partnered with a panel without an EDID. This results in us ignoring the > > connector and not lighting up the panel. > > Yeah not like this. > > you want to make the command line the *last* option we use, the final > fallback. LVDS panels have EDID and VBT hardcoded modes for a good > reason, they don't work with other modes that well. You always want to > use a scaler on the LVDS panel to do modes not the native mode. So if I > have a VBT or EDID and you set video= I should get a scaled mode, not > garbage. > > So what I suspect you really want is to leave video= alone or enhance it > somehow, or maybe add i915.lvds_native_mode= parameter. Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) system with HDMI port connected through an LVDS converter. The "panel timings" are the HDMI output mode, and it gets set through a BIOS option making it impossible to use the native resolution on the HDTV display. Ideally, it would be better if this hardware configuration could be quirked to represent the output as a HDMI connector, but programmed through the LVDS registers, but I'm not sure how feasible that is. At least being able to set custom timings for the fixed mode would be a great improvment. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > wrote: > > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) > > system with HDMI port connected through an LVDS converter. The "panel > > timings" are the HDMI output mode, and it gets set through a BIOS > > option making it impossible to use the native resolution on the HDTV > > display. > > Can you please attach the EDID for the connection and let's see if there > is any tell-tale? Unfortunately EDID doesn't seem to be making it through. /sys/devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/edid is empty so I tried read-edid, but it reported "Monitor and video card combination does not support DDC1/2 transfers". EDID was present using VGA-DVI so the TV does support EDID. (Although it didn't actually support the modes it claimed to when it determined it was connected to a PC!) I've attached dmidecode output in case it helps.# dmidecode 2.11 SMBIOS 2.6 present. 22 structures occupying 1254 bytes. Table at 0x000FB9F0. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 080016 Release Date: 12/01/2010 Address: 0xF Runtime Size: 64 kB ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.16 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: To Be Filled By O.E.M. Product Name: To Be Filled By O.E.M. Version: To Be Filled By O.E.M. Serial Number: To Be Filled By O.E.M. UUID: 03000200-0400-0500-0006-000700080009 Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: To Be Filled By O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: To be filled by O.E.M. Product Name: To be filled by O.E.M. Version: To be filled by O.E.M. Serial Number: To be filled by O.E.M. Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: To Be Filled By O.E.M. Type: Desktop Lock: Not Present Version: To Be Filled By O.E.M. Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Atom Manufacturer: Intel ID: CA 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 28, Stepping 10 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture)
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > wrote: > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > wrote: > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > (Pineview) system with HDMI port connected through an LVDS > > > > converter. The "panel timings" are the HDMI output mode, and it > > > > gets set through a BIOS option making it impossible to use the > > > > native resolution on the HDTV display. > > > > > > Can you please attach the EDID for the connection and let's see if > > > there is any tell-tale? > > > > can you guys ask someone internally about it also, there is a driver > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > > not sure what i2c bus its hanging off. > > > > Dave. > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > may or may not be the thing. > > Dave. I'll see if it works... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > - Original message - > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > > wrote: > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > > wrote: > > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > > (Pineview) system with HDMI port connected through an LVDS > > > > > converter. The "panel timings" are the HDMI output mode, and it > > > > > gets set through a BIOS option making it impossible to use the > > > > > native resolution on the HDTV display. > > > > > > > > Can you please attach the EDID for the connection and let's see if > > > > there is any tell-tale? > > > > > > can you guys ask someone internally about it also, there is a driver > > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > > > not sure what i2c bus its hanging off. > > > > > > Dave. > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > may or may not be the thing. > > > > Dave. > I'll see if it works... Is there a public clone URI for that repo? I dont want to have to download the full ChromiumOS... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > - Original message - > > - Original message - > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > wrote: > > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > > > wrote: > > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > > > wrote: > > > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > > > (Pineview) system with HDMI port connected through an LVDS > > > > > > converter. The "panel timings" are the HDMI output mode, and > > > > > > it gets set through a BIOS option making it impossible to use > > > > > > the native resolution on the HDTV display. > > > > > > > > > > Can you please attach the EDID for the connection and let's see > > > > > if there is any tell-tale? > > > > > > > > can you guys ask someone internally about it also, there is a > > > > driver somewhere in Google also for driving the LVDS->HDMI adapter > > > > but I'm not sure what i2c bus its hanging off. > > > > > > > > Dave. > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > may or may not be the thing. > > > > > > Dave. > > I'll see if it works... > Is there a public clone URI for that repo? I dont want to have to > download the full ChromiumOS... Okay, I guessed it right: http://git.chromium.org/git/chrontel.git ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > > - Original message - > > - Original message - > > > - Original message - > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > wrote: > > > > > can you guys ask someone internally about it also, there is a > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > Dave. > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > may or may not be the thing. > > > > > > > > Dave. > > > I'll see if it works... > > Is there a public clone URI for that repo? I dont want to have to > > download the full ChromiumOS... > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git Simply running the resulting executables didn't work, it fails to detect the chip, the code also references accesses through GPIO and seems it wants an nm10_gpio driver which isn't in my kernel tree. My board is an NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could well be the same hardware. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
> > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > > wrote: > > > > > > can you guys ask someone internally about it also, there is a > > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > > > Dave. > > > > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > > > may or may not be the thing. > > > > > > > > > > Dave. > > > > I'll see if it works... > > > Is there a public clone URI for that repo? I dont want to have to > > > download the full ChromiumOS... > > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git > Simply running the resulting executables didn't work, it fails to detect > the chip, the code also references accesses through GPIO and seems it > wants an nm10_gpio driver which isn't in my kernel tree. My board is an > NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could > well be the same hardware. I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while it worked fine the chrontel driver still couldn't detect the chip: XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p ./ch7036_monitor: starts Found device ID 0xff ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56 So either it isn't a ch7036 or I'm still not doing everything necessary to expose it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reset GMBUS controller after NAK
- Original message - > On Wed, 30 Mar 2011 17:07:11 +0100 > Chris Wilson wrote: > > > Once a NAK has been asserted by the slave, we need to reset the GMBUS > > controller in order to continue. This is done by asserting the Software > > Clear Interrupt bit and then clearing it again to restore operations. > > > > If we don't clear the NAK, then all future GMBUS xfers will fail, > > including DDC probes and EDID retrieval. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 > > Signed-off-by: Chris Wilson > > --- > > This one fixes the issue I was seeing on my HP test machine; LVDS DDC > probing seems to work ok once this fix is applied. > > -- Could this be related to my inability to successfully probe the ch7036 with the ChromeOS Chrontel driver? Is it worth me testing it again with this patch applied? (I'm currently waiting to hear back from Zotac, my board supplier) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reset GMBUS controller after NAK
- Original message - > On Thu, 31 Mar 2011 16:16:27 +0100, Steven Newbury > wrote: > > - Original message - > > > On Wed, 30 Mar 2011 17:07:11 +0100 > > > Chris Wilson wrote: > > > > > > > Once a NAK has been asserted by the slave, we need to reset the > > > > GMBUS controller in order to continue. This is done by asserting > > > > the Software Clear Interrupt bit and then clearing it again to > > > > restore operations. > > > > > > > > If we don't clear the NAK, then all future GMBUS xfers will fail, > > > > including DDC probes and EDID retrieval. > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 > > > > Signed-off-by: Chris Wilson > > > > --- > > > > > > This one fixes the issue I was seeing on my HP test machine; LVDS DDC > > > probing seems to work ok once this fix is applied. > > > > > > -- > > Could this be related to my inability to successfully probe the ch7036 > > with the ChromeOS Chrontel driver? Is it worth me testing it again > > with this patch applied? (I'm currently waiting to hear back from > > Zotac, my board supplier) > > Hmm. Depends, but unlikely. I would have thought the nm10_gpio driver > you were using used it's only bitbanging on the GPIO lines rather than > GMBUS. If in doubt, disable the use of GMBUS by > The GPIO is only used for HDMI hotplug detection, chip communication goes via i2c, or at least would if I could get it working... :-( ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reset GMBUS controller after NAK
- Original message - > - Original message - > > On Thu, 31 Mar 2011 16:16:27 +0100, Steven Newbury > > wrote: > > > - Original message - > > > > On Wed, 30 Mar 2011 17:07:11 +0100 > > > > Chris Wilson wrote: > > > > > > > > > Once a NAK has been asserted by the slave, we need to reset the > > > > > GMBUS controller in order to continue. This is done by asserting > > > > > the Software Clear Interrupt bit and then clearing it again to > > > > > restore operations. > > > > > > > > > > If we don't clear the NAK, then all future GMBUS xfers will fail, > > > > > including DDC probes and EDID retrieval. > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 > > > > > Signed-off-by: Chris Wilson > > > > > --- > > > > > > > > This one fixes the issue I was seeing on my HP test machine; LVDS > > > > DDC probing seems to work ok once this fix is applied. > > > > > > > > -- > > > Could this be related to my inability to successfully probe the > > > ch7036 with the ChromeOS Chrontel driver? Is it worth me testing it > > > again with this patch applied? (I'm currently waiting to hear back > > > from Zotac, my board supplier) > > > > Hmm. Depends, but unlikely. I would have thought the nm10_gpio driver > > you were using used it's only bitbanging on the GPIO lines rather than > > GMBUS. If in doubt, disable the use of GMBUS by > > > The GPIO is only used for HDMI hotplug detection, chip communication > goes via i2c, or at least would if I could get it working... :-( Since I pulled in drm-fixes I get different behaviour when probing for the ch7036, in my kernel log I now get: [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [drm] GMBUS timed out, falling back to bit banging on pin 4 [i915 gmbus dpc] [drm] GMBUS timed out, falling back to bit banging on pin 5 [i915 gmbus dpb] [drm] GMBUS timed out, falling back to bit banging on pin 6 [i915 gmbus reserved] [drm] GMBUS timed out, falling back to bit banging on pin 7 [i915 gmbus dpd] The probe still fails, on some i2c buses I get as before: XAUTHORITY=/home/mythtv/.Xauthority ./ch7036_monitor -v -p -d/dev/i2c-2 ./ch7036_monitor: starts Found device ID 0xff ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56 whilst on others: XAUTHORITY=/home/mythtv/.Xauthority ./ch7036_monitor -v -p -d/dev/i2c-4 ./ch7036_monitor: starts Write byte fail (3, 03, 04): No such device or addressFound device ID 0x ./ch7036_monitor: Fatal: Device ID 0x not the expected 0x56 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
> > > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > > > wrote: > > > > > > > can you guys ask someone internally about it also, there is a > > > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > > > > > Dave. > > > > > > > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > > > > > may or may not be the thing. > > > > > > > > > > > > Dave. > > > > > I'll see if it works... > > > > Is there a public clone URI for that repo? I dont want to have to > > > > download the full ChromiumOS... > > > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git > > Simply running the resulting executables didn't work, it fails to > > detect the chip, the code also references accesses through GPIO and > > seems it wants an nm10_gpio driver which isn't in my kernel tree. My > > board is an NM10 chipset system, as is the target "Cr48 Chrome > > Notebook" so it could well be the same hardware. > > I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while > it worked fine the chrontel driver still couldn't detect the chip: > > XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p > ./ch7036_monitor: starts > Found device ID 0xff > ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56 > > So either it isn't a ch7036 or I'm still not doing everything necessary > to expose it. > Absolutely no help from Zotac :- Unfortunately we only provide support for Windows XP, Vista, and 7 operating systems. I can suggest searching through different forums on the web for any support regarding you situation We apologize for the inconvenience Please let us know if you have any other questions ... You wouldn't think it too much to ask for a hardware company to support it's hardware and leave Windows support to Microsoft. :-( ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xf86-video-intel-2.99.912 with dri3 enabled breaks gnome-shell
On Thu, 2014-06-12 at 23:16 +0200, Hans de Goede wrote: > Hi All, > > While preparing 1.15.99.903 server + 2.99.912 intel drv packages > for Fedora 21, I noticed that both gdm and gnome-shell (tested > with startx) hang, they show the initial background screen and > then just sit there. > > Building the server with --disable-dri3, or building the > intel drv with a hacked configure.ac to make it not build > with dri3 support fixes this. > > Note this is with mesa 10.2.1, which has been build with xgl-dri3 > support, I've double checked this. > Hi Hans! Have you got to the bottom of this? I see the same thing, and also possibly with GLX contexts under XWayland also with gnome-shell. If it's the same thing, it points to the mesa i965 DRI(3) driver side rather than the DDX driver since it's not involved any more with XWayland. (using git master or latest unstable releases of relevant components) signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] DRI3 only DDX driver
I tried building the xorg intel ddx driver with only DRI3 support, with DRI1 and DRI2 disabled. glxinfo says direct rendering is enabled, but gives no core contexts*. gnome-shell appears to be using software fallback, generally there seems to be no hardware acceleration. I'm wondering if DRI3 isn't ever initialising successfully, and now there's no DRI2 to fall back to. What is the minimal kernel version for DRI3? I'm currently stuck on the 3.14 stable series due to an unresolved kernel bug (which I need to bisect...), is it too old? I remember before the intel (SNA) support landed LIBGL_DEBUG=verbose used to mention DRI3 failing, I see nothing mentioning DRI3 at all now. Is there some way of determining which DRI extension is in use? DRI3 is properly listed in xdpyinfo. * I also get no core contexts also with xwayland/glx, related? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/44] GPU scheduler for i915 driver
On Thu, 2014-06-26 at 18:23 +0100, john.c.harri...@intel.com wrote: > From: John Harrison harri...@intel.com> > > Implemented a batch buffer submission scheduler for the i915 DRM > driver. Hi John, I was just wondering what's happening with this patch series? Are you still working on it? Does it need any testing? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DRI3 only DDX driver
On Mon, 2014-09-01 at 12:09 +0100, Steven Newbury wrote: > I tried building the xorg intel ddx driver with only DRI3 support, > with DRI1 and DRI2 disabled. > > glxinfo says direct rendering is enabled, but gives no core > contexts*. > > gnome-shell appears to be using software fallback, generally there > seems to be no hardware acceleration. I'm wondering if DRI3 isn't > ever initialising successfully, and now there's no DRI2 to fall back > to. > > What is the minimal kernel version for DRI3? I'm currently stuck on > the 3.14 stable series due to an unresolved kernel bug (which I need > to bisect...), is it too old? > > I remember before the intel (SNA) support landed LIBGL_DEBUG=verbose > used to mention DRI3 failing, I see nothing mentioning DRI3 at all > now. Is there some way of determining which DRI extension is in use? > DRI3 is properly listed in xdpyinfo. > > > * I also get no core contexts also with xwayland/glx, related? As a follow-up, I think this is related to https://bugs.freedesktop.org/show_bug.cgi?id=85064 Something tells me DRI3 isn't really working with i965. This is largely going unnoticed since when DRI2 is available it's usually used instead. webkit-gtk is not falling back to DRI2 without DRI3 being specifically disabled with LIBGL_DRI3_DISABLE=1. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DRI3 only DDX driver
On Fri, 2014-10-17 at 11:13 +0100, Steven Newbury wrote: > On Mon, 2014-09-01 at 12:09 +0100, Steven Newbury wrote: > > I tried building the xorg intel ddx driver with only DRI3 support, > > with DRI1 and DRI2 disabled. > > > > glxinfo says direct rendering is enabled, but gives no core > > contexts*. > > > > gnome-shell appears to be using software fallback, generally there > > seems to be no hardware acceleration. I'm wondering if DRI3 isn't > > ever initialising successfully, and now there's no DRI2 to fall > > back > > to. > > > > What is the minimal kernel version for DRI3? I'm currently stuck > > on > > the 3.14 stable series due to an unresolved kernel bug (which I > > need > > to bisect...), is it too old? > > > > I remember before the intel (SNA) support landed > > LIBGL_DEBUG=verbose > > used to mention DRI3 failing, I see nothing mentioning DRI3 at all > > now. Is there some way of determining which DRI extension is in > > use? > > DRI3 is properly listed in xdpyinfo. > > > > > > * I also get no core contexts also with xwayland/glx, related? > > As a follow-up, I think this is related to > https://bugs.freedesktop.org/show_bug.cgi?id=85064 > > Something tells me DRI3 isn't really working with i965. This is > largely going unnoticed since when DRI2 is available it's usually > used > instead. webkit-gtk is not falling back to DRI2 without DRI3 being > specifically disabled with LIBGL_DRI3_DISABLE=1. > Sorry for replying to myself again! I should have mentioned, I'm back on the current kernel now, so that can be eliminated. I get the same behaviour with uxa/glamor backends as with sna. It's still suspicious to me that core contexts are unavailable with DRI3, either with the intel driver build with --disable-dri2, or from xwayland. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
