Re: [Intel-gfx] Re : Does xf86-video-intel 2.11.0 support interlace? Lucid 2.6.33
On Thu, Jun 3, 2010 at 11:33 AM, Xavier de Almeida wrote: > Yes it's the same issue. > Thanks for poiting me to right link. > > It looks like no one cares to get this solved as this has been opened since > 2007? > at least intel drivers do support this mode on Windows and from the product > datasheet nothing was said around no support of interlace under linux > :-( A feature matrix of the driver would be handy in that respect, to see what's supported and what's not (compared to the windows driver). Cheers, Sander ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Intel GMA HD reference docs?
When will the GMA HD reference docs become available? Thanks, Sander -- "The sands of time were eroded by The river of constant change." ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel GMA HD reference docs?
On Fri, Jun 4, 2010 at 12:29 PM, Adam Jackson wrote: > On Fri, 2010-06-04 at 10:40 -0500, Sander Jansen wrote: >> When will the GMA HD reference docs become available? > > If you mean Core i3/i5 (Ironlake), then: > > http://www.x.org/docs/intel/HD/ > > - ajax > Ah thanks. I was looking at http://intellinuxgraphics.org/ and didn't find them there. Sander -- "The sands of time were eroded by The river of constant change." ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Re : Re : Re : Does xf86-video-intel 2.11.0 support interlace? Lucid 2.6.33
On Mon, Jun 7, 2010 at 12:29 PM, Xavier de Almeida wrote: > Here is the right link: > https://bugs.freedesktop.org/show_bug.cgi?id=11220 > id 11220 > > I found in the motherboard documentation that 5.1 is not supported over HDMI > (you can still have DTS-HD/True-HD on 2.0). > I assume that SPDIF should allow to have 5.1 True/DTS-HD. > Don't know the exact spec for True/DTS-HD, but most likely SPDIF doesn't have enough bandwidth to handle that. SPDIF cannot even do more than 2 channels of PCM. So with SPDIF you're stuck with Dolby Digital, DTS or 2ch PCM. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote: > Hi Christopher, > >> The log does confirm that the drm_edid_to_eld function is running, and >> that we're not far from a solution: >> [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 >> [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 > > It looks all sane to this point. > >> As for where I am getting the EDID dump from, I am getting it from >> /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, >> which provides direct virtual access to the EDID response of the >> connected device. >> >> I'm completely confident that the device doesn't report too small of a >> buffer size, and that it's completely compliant with the spec: If you > > Agreed. > >> have a Windows virtual machine (or if you're masochistic enough - a real >> machine) you should download the excellent, free "Monitor Asset Manager" >> by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It >> will let you analyze EDID + ELD + extended timings, etc from an EDID >> dump, such as the one taken above. It understands every part of EDID. >> >> I've put together a small archive containing my exact EDID binary dump >> (taken from the above device path), the FULL dmesg log, as well as >> EnTech's interpretation of the EDID dump, showing the full list of >> supported channels, formats, etc. >> >> I'm guessing there is some tiny bug in your interpretation of how to >> read ELD, maybe an incorrect 1 byte offset or something like that. >> >> Here's the pack: >> http://www.pulseforce.com/node/edid_to_eld.zip > > Thanks! It's great tool and information! > >> If you do a hex analysis of my EDID dump and compare it to what the >> edid_to_eld function is trying to do, it will probably show what's >> wrong. I'd love to have a look at that myself but am really busy with a >> project over here so I can't help out other than to recompile and test >> as fast as I can. > > Would you install the "intel-gpu-tools" package and run its > intel_audio_dump utility? If not shipped with your distribution, the > source code is also available in > > git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools > > You'll need to install packages "autotools-dev pkg-config > libpciaccess-dev libdrm-dev libdrm-intel1" in order to build it from > source. > > intel_audio_dump will dump the ELD data in the hardware buffer for use > by the audio driver. By verifying if that data is correct, we are able > to analyze whether and how the audio driver goes wrong. > I think I experience similar issues. In my case the multi-channel pcm playback through HDMI doesn't work. Stereo and passthrough seem to work fine though !? It's hookedup to my TV via a yamaha receiver. I'm currently running Linux 3.1 with a G45 chipset. libdrm 2.4.27-1 xf86-video-intel 2.16.0-1 The eld seems be incorrectly parsed, though the kernel log didn't give much info. The eld info from alsa is rather empty: cat /proc/asound/Intel/eld#3.0 monitor_present 1 eld_valid 0 Using the same Monitor Asset Manager I was able to verify that the edid from (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid ) does seem to contain the correct information. I've attached both the edid and the output of Monitor Asset Manager.In addition I also run the intel_audio_dump. Let me know if you need anymore information. Cheers, Sander PS. Hope the attachments are not too big. Monitor Model name... SAMSUNG Manufacturer. Samsung Plug and Play ID. SAM050D Serial number 1 Manufacture date. 2008, ISO week 48 Filter driver None - EDID revision 1.3 Input signal type Digital Color bit depth.. Undefined Display type. RGB color Screen size.. 160 x 90 mm (7.2 in) Power management. Not supported Extension blocs.. 1 (CEA-EXT) - DDC/CI... n/a Color characteristics Default color space.. Non-sRGB Display gamma 2.20 Red chromaticity. Rx 0.640 - Ry 0.330 Green chromaticity... Gx 0.300 - Gy 0.600 Blue chromaticity Bx 0.150 - By 0.060 White point (default) Wx 0.313 - Wy 0.329 Additional descriptors... None Timing characteristics Horizontal scan range 26-81kHz Vertical scan range.. 24-75Hz Video bandwidth.. 150MHz CVT standard. Not supported GTF standard. Not supported Additional descriptors... None Preferred timing. Yes Native/preferred timing.. 1920x1080p at 60Hz (16:9) Modeline... "1920x1080" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Detailed timing #1... 1280x720p at 60Hz (16:9) Modeline... "1280x720" 74.250 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Standard timings supported 720 x 400p at
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel wrote: > Dear Sander, > > > Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen: >> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote: > >> >> The log does confirm that the drm_edid_to_eld function is running, and >> >> that we're not far from a solution: >> >> [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 >> >> [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 >> > >> > It looks all sane to this point. >> > >> >> As for where I am getting the EDID dump from, I am getting it from >> >> /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, >> >> which provides direct virtual access to the EDID response of the >> >> connected device. >> >> >> >> I'm completely confident that the device doesn't report too small of a >> >> buffer size, and that it's completely compliant with the spec: If you >> > >> > Agreed. >> > >> >> have a Windows virtual machine (or if you're masochistic enough - a real >> >> machine) you should download the excellent, free "Monitor Asset Manager" >> >> by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It >> >> will let you analyze EDID + ELD + extended timings, etc from an EDID >> >> dump, such as the one taken above. It understands every part of EDID. >> >> >> >> I've put together a small archive containing my exact EDID binary dump >> >> (taken from the above device path), the FULL dmesg log, as well as >> >> EnTech's interpretation of the EDID dump, showing the full list of >> >> supported channels, formats, etc. >> >> >> >> I'm guessing there is some tiny bug in your interpretation of how to >> >> read ELD, maybe an incorrect 1 byte offset or something like that. >> >> >> >> Here's the pack: >> >> http://www.pulseforce.com/node/edid_to_eld.zip >> > >> > Thanks! It's great tool and information! >> > >> >> If you do a hex analysis of my EDID dump and compare it to what the >> >> edid_to_eld function is trying to do, it will probably show what's >> >> wrong. I'd love to have a look at that myself but am really busy with a >> >> project over here so I can't help out other than to recompile and test >> >> as fast as I can. >> > >> > Would you install the "intel-gpu-tools" package and run its >> > intel_audio_dump utility? If not shipped with your distribution, the >> > source code is also available in >> > >> > git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools >> > >> > You'll need to install packages "autotools-dev pkg-config >> > libpciaccess-dev libdrm-dev libdrm-intel1" in order to build it from >> > source. >> > >> > intel_audio_dump will dump the ELD data in the hardware buffer for use >> > by the audio driver. By verifying if that data is correct, we are able >> > to analyze whether and how the audio driver goes wrong. >> > >> >> I think I experience similar issues. In my case the multi-channel pcm >> playback through HDMI doesn't work. Stereo and passthrough seem to >> work fine though !? It's hookedup to my TV via a yamaha receiver. >> >> I'm currently running Linux 3.1 with a G45 chipset. >> >> libdrm 2.4.27-1 >> xf86-video-intel 2.16.0-1 > > do you have Fengguang’s patch applied? This thread is about testing that > patch. > >> The eld seems be incorrectly parsed, though the kernel log didn't give >> much info. The eld info from alsa is rather empty: >> >> cat /proc/asound/Intel/eld#3.0 >> monitor_present 1 >> eld_valid 0 >> >> Using the same Monitor Asset Manager I was able to verify that the edid from >> (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid >> ) does seem to contain the correct information. >> >> I've attached both the edid and the output of Monitor Asset Manager.In >> addition I also run the intel_audio_dump. >> >> Let me know if you need anymore information. > > It would be great if you could test the patch. Ah, that explains. I was under the impression this was already in 3.1 (but then again, it was rather late for me :) ) I will give the patch a try and report back. . Thanks, Sander ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
On Wed, Nov 2, 2011 at 6:17 AM, Sander Jansen wrote: > On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel > wrote: >> Dear Sander, >> >> >> Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen: >>> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote: >> >>> >> The log does confirm that the drm_edid_to_eld function is running, and >>> >> that we're not far from a solution: >>> >> [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 >>> >> [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 >>> > >>> > It looks all sane to this point. >>> > >>> >> As for where I am getting the EDID dump from, I am getting it from >>> >> /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, >>> >> which provides direct virtual access to the EDID response of the >>> >> connected device. >>> >> >>> >> I'm completely confident that the device doesn't report too small of a >>> >> buffer size, and that it's completely compliant with the spec: If you >>> > >>> > Agreed. >>> > >>> >> have a Windows virtual machine (or if you're masochistic enough - a real >>> >> machine) you should download the excellent, free "Monitor Asset Manager" >>> >> by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It >>> >> will let you analyze EDID + ELD + extended timings, etc from an EDID >>> >> dump, such as the one taken above. It understands every part of EDID. >>> >> >>> >> I've put together a small archive containing my exact EDID binary dump >>> >> (taken from the above device path), the FULL dmesg log, as well as >>> >> EnTech's interpretation of the EDID dump, showing the full list of >>> >> supported channels, formats, etc. >>> >> >>> >> I'm guessing there is some tiny bug in your interpretation of how to >>> >> read ELD, maybe an incorrect 1 byte offset or something like that. >>> >> >>> >> Here's the pack: >>> >> http://www.pulseforce.com/node/edid_to_eld.zip >>> > >>> > Thanks! It's great tool and information! >>> > >>> >> If you do a hex analysis of my EDID dump and compare it to what the >>> >> edid_to_eld function is trying to do, it will probably show what's >>> >> wrong. I'd love to have a look at that myself but am really busy with a >>> >> project over here so I can't help out other than to recompile and test >>> >> as fast as I can. >>> > >>> > Would you install the "intel-gpu-tools" package and run its >>> > intel_audio_dump utility? If not shipped with your distribution, the >>> > source code is also available in >>> > >>> > git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools >>> > >>> > You'll need to install packages "autotools-dev pkg-config >>> > libpciaccess-dev libdrm-dev libdrm-intel1" in order to build it from >>> > source. >>> > >>> > intel_audio_dump will dump the ELD data in the hardware buffer for use >>> > by the audio driver. By verifying if that data is correct, we are able >>> > to analyze whether and how the audio driver goes wrong. >>> > >>> >>> I think I experience similar issues. In my case the multi-channel pcm >>> playback through HDMI doesn't work. Stereo and passthrough seem to >>> work fine though !? It's hookedup to my TV via a yamaha receiver. >>> >>> I'm currently running Linux 3.1 with a G45 chipset. >>> >>> libdrm 2.4.27-1 >>> xf86-video-intel 2.16.0-1 >> >> do you have Fengguang’s patch applied? This thread is about testing that >> patch. >> >>> The eld seems be incorrectly parsed, though the kernel log didn't give >>> much info. The eld info from alsa is rather empty: >>> >>> cat /proc/asound/Intel/eld#3.0 >>> monitor_present 1 >>> eld_valid 0 >>> >>> Using the same Monitor Asset Manager I was able to verify that the edid from >>> (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid >>> ) does seem to contain the correct information. >>> >>> I've attached both the
Re: [Intel-gfx] Pineview + libva
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. 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... Cheers, Sander ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
