Re: [PATCH 7/9] drm/edid: Expose mandatory stereo modes for HDMI sinks
Damien Lespiau intel.com> writes:
> +static const struct s3d_mandatory_mode s3d_mandatory_modes[] = {
> + { 1920, 1080, 24, 0,
> + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING
},
> + { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE,
> + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> + { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE,
> + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> + { 1280, 720, 50, 0,
> + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING
},
> + { 1280, 720, 60, 0,
> + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
> +};
I may be missing something here... But..
The frame packed modes are much higher in pixels than this and include frame
packing.
1080*2+45=2050
720*2+30=1470
Unless you intend to hide the left/right split in mesa or other place, we
need to get the ability to render to both fields somehow.
Either as the full 2050 pixels high or at 1080*2 and the driver adds the
blanking.
Also, some logic aught to indicate pixel aspect ratio for the modes since
they are non square for the half res modes.
/Joakim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl
David Herrmann gmail.com> writes: > > So just to be clear: Whenever a mode is present with 3D flags, it is > also a valid non-3D mode? Is this guaranteed? > Well.. Some HDTV's will when they receive a frame packed mode (1080*2+45=2205 pixels high) . Display just the top part. The bottom part of that is not on screen. So while it will not display it as 3d, it will discard half of the image. /Joakim ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[i915] Backlight brighter since 3.9.0
Hi, > > 2013/5/20 Daniel Vetter ffwll.ch> > Yeah, this is a feature. HDMI has (for oddball backwards compat with > analog TV signals) a special mode which reduces the useable RGB value > range by chopping off about 10% at the bottom and top end. This results in > light colors getting brighter and dark colors getting darker. > The above mentioned commit tries (to the best of our knowledge) to > auto-set the option which most likely fits what the hdmi sink will do with > the color data. You can either fix this up in the hdmi sink with the > on-screen menu or by manually setting the "RBG Broadcast" property for the > relevant hdmi connector to the setting you want. > Cheers, Daniel-- > Daniel Vetter > Software Engineer, Intel Corporation+41 (0) 79 365 57 48?- http://blog.ffwll.ch > Does this mean the system is doing RGB full range to limited range compression on the raw RGB data it receives from an application? Ie a video player that want to be able to handle blacker than black properly will need to force the GPU into fullrange output to avoid the driver internal compression of the signal and handle that itself? /Joakim
Re: [i915] Backlight brighter since 3.9.0
Hi, > > 2013/5/20 Daniel Vetter ffwll.ch> > Yeah, this is a feature. HDMI has (for oddball backwards compat with > analog TV signals) a special mode which reduces the useable RGB value > range by chopping off about 10% at the bottom and top end. This results in > light colors getting brighter and dark colors getting darker. > The above mentioned commit tries (to the best of our knowledge) to > auto-set the option which most likely fits what the hdmi sink will do with > the color data. You can either fix this up in the hdmi sink with the > on-screen menu or by manually setting the "RBG Broadcast" property for the > relevant hdmi connector to the setting you want. > Cheers, Daniel-- > Daniel Vetter > Software Engineer, Intel Corporation+41 (0) 79 365 57 48 - http://blog.ffwll.ch > Does this mean the system is doing RGB full range to limited range compression on the raw RGB data it receives from an application? Ie a video player that want to be able to handle blacker than black properly will need to force the GPU into fullrange output to avoid the driver internal compression of the signal and handle that itself? /Joakim ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes
Ville Syrj?l? linux.intel.com> writes: > I think I'll defer on that one until we decide whether we want add > both 60Hz and 59.94HZ versions to the connector's mode list. Daniel > suggested we do it, but I disagree slightly since CEA-861 says that > monitors should only advertise one variant in their detailed timings. > I was thinking that we'd follow that rule here as well. But I can > be easily convinced otherwise, in case someone else has an > opinion... > Please add both. From a video player's perspective. The choice matters a lot.
Re: [PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes
Ville Syrjälä linux.intel.com> writes: > I think I'll defer on that one until we decide whether we want add > both 60Hz and 59.94HZ versions to the connector's mode list. Daniel > suggested we do it, but I disagree slightly since CEA-861 says that > monitors should only advertise one variant in their detailed timings. > I was thinking that we'd follow that rule here as well. But I can > be easily convinced otherwise, in case someone else has an > opinion... > Please add both. From a video player's perspective. The choice matters a lot. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
> > > > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000. Only > > issue is that changing it will break any app relying on it being REALTIME clock. > > > > App that rely on it being anything special are badly broken and i > don't think there is any such app. The specification strongly stress > that app should make no assumption about it. > While that may be true... Since there is no other API for getting this UST clock, it's somewhat limited in use. Even if i know vsync happened at time X, if don't know what time it is "now" how can i make use of it? Spec says: "The Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system." If across the system, the only API to get to this value is through GLX api, it's rather hard to make use of. For example syncing audio to vsync. One need to sync audio output written to audio renderer now, with this clock. Also regarding relying on current behavior... Even if this change is made now, there will be a lot of system with the old behaviour. So knowning if the change has been made in a system is crucial for supporting both / not enabling when feature is unreliable. /Joakim
Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
> > > > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000. Only > > issue is that changing it will break any app relying on it being REALTIME clock. > > > > App that rely on it being anything special are badly broken and i > don't think there is any such app. The specification strongly stress > that app should make no assumption about it. > While that may be true... Since there is no other API for getting this UST clock, it's somewhat limited in use. Even if i know vsync happened at time X, if don't know what time it is "now" how can i make use of it? Spec says: "The Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter that is available throughout the system." If across the system, the only API to get to this value is through GLX api, it's rather hard to make use of. For example syncing audio to vsync. One need to sync audio output written to audio renderer now, with this clock. Also regarding relying on current behavior... Even if this change is made now, there will be a lot of system with the old behaviour. So knowning if the change has been made in a system is crucial for supporting both / not enabling when feature is unreliable. /Joakim ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
Michel D?nzer daenzer.net> writes: > > > > > > From the GLX_OML_sync_control spec: > > > > > > The Unadjusted System Time (or UST) is a 64-bit monotonically > > > increasing counter [...] > > >
Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
Michel Dänzer daenzer.net> writes: > > > > > > From the GLX_OML_sync_control spec: > > > > > > The Unadjusted System Time (or UST) is a 64-bit monotonically > > > increasing counter [...] > > > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000. Only issue is that changing it will break any app relying on it being REALTIME clock. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
Hi, I'm currently trying to make use of OML_sync_control extension to schedule presentation of video frames in xbmc. I've run into somewhat of a snag. It seem the spec doesn't specify what time the UST clock really is, nor can i find any mention of it elsewhere in docs. Code wise it seem to be using do_gettimeofday(), which seems like a rather poor choice given that it can jump forward and back in time due to settimeofday calls. We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display of video frames, so to avoid major changes I'd need a way to convert to gettimeofday (seem same as CLOCK_REALTIME). Currently i'm trying: struct timespec mon, rel; clock_gettime(CLOCK_MONOTONIC, &mon); clock_gettime(CLOCK_REALTIME , &rel); ticks += (rel.tv_sec - mon.tv_sec) * 10; ticks += (rel.tv_nsec - mon.tv_nsec); To convert between the two, but that is quite a hack both in the possibility of clock changes and scheduling errors. Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC in the first place? Regards /Joakim
RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
Hi, I'm currently trying to make use of OML_sync_control extension to schedule presentation of video frames in xbmc. I've run into somewhat of a snag. It seem the spec doesn't specify what time the UST clock really is, nor can i find any mention of it elsewhere in docs. Code wise it seem to be using do_gettimeofday(), which seems like a rather poor choice given that it can jump forward and back in time due to settimeofday calls. We normally make use of clock_gettime(CLOCK_MONOTONIC) to timestamp display of video frames, so to avoid major changes I'd need a way to convert to gettimeofday (seem same as CLOCK_REALTIME). Currently i'm trying: struct timespec mon, rel; clock_gettime(CLOCK_MONOTONIC, &mon); clock_gettime(CLOCK_REALTIME , &rel); ticks += (rel.tv_sec - mon.tv_sec) * 10; ticks += (rel.tv_nsec - mon.tv_nsec); To convert between the two, but that is quite a hack both in the possibility of clock changes and scheduling errors. Is there a better way, or perhaps the DRI code should use CLOCK_MONOTONIC in the first place? Regards /Joakim ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm_edid: support CEA video modes
Joakim Plate ecce.se> writes: > > Christian Schmidt digadd.de> writes: > > > > > TFT/plasma televisions and projectors have become commonplace, and so > > has the use of PCs to drive them. Add the video modes specified by an > > EDID's CEA extension to the mode database for a connector. > > /Joakim > Shameless bump on the subject. Would be nice if we could get this list complete when connecting to HDTV's.
Re: [PATCH] drm_edid: support CEA video modes
Joakim Plate ecce.se> writes: > > Christian Schmidt digadd.de> writes: > > > > > TFT/plasma televisions and projectors have become commonplace, and so > > has the use of PCs to drive them. Add the video modes specified by an > > EDID's CEA extension to the mode database for a connector. > > /Joakim > Shameless bump on the subject. Would be nice if we could get this list complete when connecting to HDTV's. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm_edid: support CEA video modes
Christian Schmidt digadd.de> writes: > > TFT/plasma televisions and projectors have become commonplace, and so > has the use of PCs to drive them. Add the video modes specified by an > EDID's CEA extension to the mode database for a connector. Hi, Looking over this i noticed that this patch adds an incomplete list of video modes. For many of the short descriptors, two modes should be added. One for a integer refreshrate and one for the old ntsc rate (rate*1000/1001). Would be nice to see that resolved since it's rather crucial to get right for video playback. /Joakim
Re: [PATCH] drm_edid: support CEA video modes
Christian Schmidt digadd.de> writes: > > TFT/plasma televisions and projectors have become commonplace, and so > has the use of PCs to drive them. Add the video modes specified by an > EDID's CEA extension to the mode database for a connector. Hi, Looking over this i noticed that this patch adds an incomplete list of video modes. For many of the short descriptors, two modes should be added. One for a integer refreshrate and one for the old ntsc rate (rate*1000/1001). Would be nice to see that resolved since it's rather crucial to get right for video playback. /Joakim ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
