[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #3 from Michel Dänzer 2011-05-23 00:31:17 PDT --- Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex . Does running thread apply all bt full in gdb give backtraces for any other threads? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #4 from Ernst Sjöstrand 2011-05-23 01:18:46 PDT --- Yes, it's probably when a new window is created or similar. But just opening 100 gnome-terminals doesn't trigger it so it's not super easy to trigger. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] New: texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 Summary: texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1 Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: neno...@systeminplace.net hi, i get texture corruption as seen in the attached screenshot when using dri2. when running more 3D intensive applications (like say, etracer), the texture corruption increases resulting in some graphics primitives not being rendered. this does not happen with DRI1, with DRI1, there is no corruption and all primitives are rendered as expected. this is on linux 2.6.38.6 with alpine patches, mesa 7.10.2 and xorg 1.10 with xf86-video-ati 6.14.1, libdrm 2.4.25 and uclibc 0.9.32-rc3 (also with alpine patches). there are some bugs that look similar to what i am seeing, but they are all marked RESOLVED, and none of them mention DRI2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #1 from William Pitcock 2011-05-23 02:00:48 PDT --- it seems that attachment sizes are limited. see http://nenolod.net/~nenolod/radeon-dri2-gltexture-corruption.png for an example of what i am seeing. i think this is due to incomplete writes to the card or perhaps an off-by-one of some kind. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #2 from William Pitcock 2011-05-23 02:36:47 PDT --- oh, i forgot to mention, this is on a dual radeon hd 4870 setup. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Standardize YUV support in the fbdev API
On Monday, May 23, 2011 13:55:21 Marek Szyprowski wrote: > Hello, > > On Wednesday, May 18, 2011 8:54 AM Hans Verkuil wrote: > > > On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: > > > On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart > > > wrote: > > > > I need to implement support for a YUV frame buffer in an fbdev driver. > > As the > > > > fbdev API doesn't support this out of the box, I've spent a couple of > > days > > > > reading fbdev (and KMS) code and thinking about how we could cleanly > > add YUV > > > > support to the API. I'd like to share my findings and thoughts, and > > hopefully > > > > receive some comments back. > > > > > > > > The terms 'format', 'pixel format', 'frame buffer format' and 'data > > format' > > > > will be used interchangeably in this e-mail. They all refer to the way > > pixels > > > > are stored in memory, including both the representation of a pixel as > > integer > > > > values and the layout of those integer values in memory. > > > > > > This is a great proposal. It was about time! > > > > > > > The third solution has my preference. Comments and feedback will be > > > > appreciated. I will then work on a proof of concept and submit patches. > > > > > > I also would prefer the third solution. I don't think there's much > > > difference from the user-space point of view, and a new ioctl would be > > > cleaner. Also the v4l2 fourcc's should do. > > > > I agree with this. > > > > We might want to take the opportunity to fix this section of the V4L2 Spec: > > > > http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb > > > > There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and > > should be removed. > > That's definitely true. I was confused at the beginning when I saw 2 > different tables describing the same pixel formats. > > I suspect many if not all V4L2 drivers are badly broken for > > big-endian systems and report the wrong pixel formats. > > > > Officially the pixel formats reflect the contents of the memory. But > > everything is swapped on a big endian system, so you are supposed to > > report a different pix format. > > I always thought that pix_format describes the layout of video data in > memory on byte level, which is exactly the same on both little- and big- > endian systems. Correct. > You can notice swapped data only if you access memory > by units larger than byte, like 16bit or 32bit integers. BTW - I would > really like to avoid little- and big- endian flame, but your statement > about 'everything is swapped on a big endian system' is completely > wrong. It is rather the characteristic of little-endian system not big > endian one if you display the content of the same memory first using > byte access and then using word/long access. You are correct, I wasn't thinking it through. > > I can't remember seeing any driver do that. Some have built-in swapping, > > though, and turn that on if needed. > > The drivers shouldn't do ANY byte swapping at all. Only tools that > extract pixel data with some 'accelerated' methods (like 32bit integer > casting and bit-level shifting) should be aware of endianess. > > > I really need to run some tests, but I've been telling myself this for > > years now :-( > > I've checked the BTTV board in my PowerMac/G4 and the display was > correct with xawtv. It is just a matter of selecting correct pix format > basing on the information returned by xsever. > > Best regards > Just forget my post (except for the part of cleaning up the tables :-) ). Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #3 from Alex Deucher 2011-05-23 05:49:22 PDT --- Please attach your xorg log, dmesg output, and glxinfo output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC] Standardize YUV support in the fbdev API
Hello, On Wednesday, May 18, 2011 8:54 AM Hans Verkuil wrote: > On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: > > On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart > > wrote: > > > I need to implement support for a YUV frame buffer in an fbdev driver. > As the > > > fbdev API doesn't support this out of the box, I've spent a couple of > days > > > reading fbdev (and KMS) code and thinking about how we could cleanly > add YUV > > > support to the API. I'd like to share my findings and thoughts, and > hopefully > > > receive some comments back. > > > > > > The terms 'format', 'pixel format', 'frame buffer format' and 'data > format' > > > will be used interchangeably in this e-mail. They all refer to the way > pixels > > > are stored in memory, including both the representation of a pixel as > integer > > > values and the layout of those integer values in memory. > > > > This is a great proposal. It was about time! > > > > > The third solution has my preference. Comments and feedback will be > > > appreciated. I will then work on a proof of concept and submit patches. > > > > I also would prefer the third solution. I don't think there's much > > difference from the user-space point of view, and a new ioctl would be > > cleaner. Also the v4l2 fourcc's should do. > > I agree with this. > > We might want to take the opportunity to fix this section of the V4L2 Spec: > > http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb > > There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and > should be removed. That's definitely true. I was confused at the beginning when I saw 2 different tables describing the same pixel formats. I suspect many if not all V4L2 drivers are badly broken for > big-endian systems and report the wrong pixel formats. > > Officially the pixel formats reflect the contents of the memory. But > everything is swapped on a big endian system, so you are supposed to > report a different pix format. I always thought that pix_format describes the layout of video data in memory on byte level, which is exactly the same on both little- and big- endian systems. You can notice swapped data only if you access memory by units larger than byte, like 16bit or 32bit integers. BTW - I would really like to avoid little- and big- endian flame, but your statement about 'everything is swapped on a big endian system' is completely wrong. It is rather the characteristic of little-endian system not big endian one if you display the content of the same memory first using byte access and then using word/long access. > I can't remember seeing any driver do that. Some have built-in swapping, > though, and turn that on if needed. The drivers shouldn't do ANY byte swapping at all. Only tools that extract pixel data with some 'accelerated' methods (like 32bit integer casting and bit-level shifting) should be aware of endianess. > I really need to run some tests, but I've been telling myself this for > years now :-( I've checked the BTTV board in my PowerMac/G4 and the display was correct with xawtv. It is just a matter of selecting correct pix format basing on the information returned by xsever. Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37471] Website with information about maintainers/developers
https://bugs.freedesktop.org/show_bug.cgi?id=37471 --- Comment #1 from Brian Paul 2011-05-23 07:49:02 PDT --- I think it would be hard to keep that info up to date. If you're wondering who's most recently been working on a particular driver, the best thing to do is check the git history. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 Sven Arvidsson changed: What|Removed |Added CC||s...@whiz.se --- Comment #1 from Sven Arvidsson 2011-05-23 10:12:27 PDT --- This is the same as bug 33188 isn't it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #4 from Fredrik Höglund 2011-05-23 10:22:09 PDT --- Judging by the screenshot this may be a duplicate of bug 33824. The logout effect in KWin uses automatically generated mipmaps + LOD bias to blur all windows except the dialog in the center of the screenshot. Does the problem go away if you set ColorTiling to False in your xorg.conf file? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37513] New: WebGL in Chrome: BadDrawable
https://bugs.freedesktop.org/show_bug.cgi?id=37513 Summary: WebGL in Chrome: BadDrawable Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se When running part of the WebGL conformance test, buffer-preserve-test.html, this error is repeated on the terminal and Chrome later crashes: [10066:10066:23755423156:ERROR:x11_util.cc(862)] X Error detected: serial 111, error_code 9 (BadDrawable (invalid Pixmap or Window parameter)), request_code 137, minor_code 8 (DRI2SwapBuffers) Chrome needs to be run with --ignore-gpu-blacklist --enable-webgl System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: git-fd6f2d6 -- drm: 2.4.25 -- kernel: 2.6.39 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #5 from Tobias Jakobi 2011-05-23 10:31:38 PDT --- This is most likely _no_ duplicate, since tiling still has to be force on with an envvar. And I don't see this happening from the explanations in the initial post. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix typo in spread spectrum code
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 48f5ff0..ec84878 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -440,7 +440,7 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
case ATOM_PPLL_INVALID:
return;
}
- args.v2.ucEnable = enable;
+ args.v3.ucEnable = enable;
if ((ss->percentage == 0) || (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v3.ucEnable = ATOM_DISABLE;
} else if (ASIC_IS_DCE4(rdev)) {
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/cayman: fix typo in register mask
Noticed by Droste on IRC. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/nid.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index b2088c1..9736746 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -353,7 +353,7 @@ #defineMULTI_GPU_TILE_SIZE_MASK0x0300 #defineMULTI_GPU_TILE_SIZE_SHIFT 24 #defineROW_SIZE(x) ((x) << 28) -#defineROW_SIZE_MASK 0x3007 +#defineROW_SIZE_MASK 0x3000 #defineROW_SIZE_SHIFT 28 #defineNUM_LOWER_PIPES(x) ((x) << 30) #defineNUM_LOWER_PIPES_MASK0x4000 -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
So I've been busily merging stuff, and just wanted to send out a quick reminder that I warned people in the 39 announcement that this might be a slightly shorter merge window than usual, so that I can avoid having to make the -rc1 release from Japan using my slow laptop (doing "allyesconfig" builds on that thing really isn't in the cards, and I like to do those to verify things - even if we've already had a few cases where arch include differences made it less than effective in finding problems). And judging by the merge window so far, that early close (probably Sunday - I'll be on airplanes next Monday) looks rather likely. I already seem to have a fairly sizable portion of linux-next in my tree, and there haven't been any huge upsets. So anybody who was planning a last-minute "please pull" - this is a heads-up. Don't do it, you might miss the window entirely. Did I miss any major development mailing lists with stuff pending? Linus PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I listen.
If you do this, I will buy you a bottle of whatever whiskey you want
that I can get my hands on in Tokyo next week.
{crosses fingers}
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #6 from William Pitcock 2011-05-23 12:45:35 PDT --- re: color tiling, i believe it is disabled by default, but i will try and see if that is the problem. i will also get dmesg / Xorg logs when i switch back over to DRI2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #10 from Benjamin Bellec 2011-05-23 13:12:37 PDT --- In fact, I have these 2 issues also with gallium-swrast. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, 23 May 2011 21:25:25 +0200 (CEST) Thomas Gleixner wrote: > On Mon, 23 May 2011, Linus Torvalds wrote: > > PS. The voices in my head also tell me that the numbers are getting > > too big. I may just call the thing 2.8.0. And I almost guarantee that > > this PS is going to result in more discussion than the rest, but when > > the voices tell me to do things, I listen. > > So the voices tell you to avoid .42 ? They tell him to avoid the question to which 42 is the answer. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > I really hope there's also a voice that tells you to wait until .42 before > cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be "3.0", not "3.0.0" - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying "we're about to start the third decade" works as well as any other excuse. But we'll see. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Standardize YUV support in the fbdev API
Hi Florian,
On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
> On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > I need to implement support for a YUV frame buffer in an fbdev driver. As
> > the fbdev API doesn't support this out of the box, I've spent a couple
> > of days reading fbdev (and KMS) code and thinking about how we could
> > cleanly add YUV support to the API. I'd like to share my findings and
> > thoughts, and hopefully receive some comments back.
>
> Thanks. I think you did already a good job, hope we can get it done this
> time.
Thanks. I'll keep pushing then :-)
> > Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share
> > data and buffers between those subsystems, and the planned use of V4L2
> > FCCs in the KMS overlay API, I believe using V4L2 FCCs to identify fbdev
> > formats would be a wise decision.
>
> I agree.
There seems to be a general agreement on this, so I'll consider this settled.
> > To select a frame buffer YUV format, the fb_var_screeninfo structure will
> > need to be extended with a format field. The fbdev API and ABI must not
> > be broken, which prevents us from changing the current structure layout
> > and replacing the existing format selection mechanism (through the red,
> > green, blue and alpha bitfields) completely.
>
> I agree.
>
> > - Other solutions are possible, such as adding new ioctls. Those
> > solutions are more intrusive, and require larger changes to both
> > userspace and kernelspace code.
>
> I'm against (ab)using the nonstd field (probably the only sane thing we can
> do with it is declare it non-standard which interpretation is completely
> dependent on the specific driver) or requiring previously unused fields to
> have a special value so I'd like to suggest a different method:
>
> I remembered an earlier discussion:
> [ http://marc.info/?l=linux-fbdev&m=129896686208130&w=2 ]
>
> On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
> > On Tue, Mar 1, 2011 at 04:13, Damian wrote:
> >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
> >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
> >>> FB_VISUAL_*
> >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
> >>> fields are
> >>> YCbCr instead of RGB.
> >>> Depending on the frame buffer organization, you also need new
> >>> FB_TYPE_*/FB_AUX_*
> >>> types.
> >>
> >> I just wanted to clarify here. Is your comment about these new flags
> >> in specific reference to this patch or to Magnus' "going forward"
> >> comment? It
> >
> > About new flags.
> >
> >> seems like the beginnings of a method to standardize YCbCr support in
> >> fbdev across all platforms.
> >> Also, do I understand correctly that FB_VISUAL_ would specify the
> >> colorspace
> >
> > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
> > to colors on the screen, so to me it looks like the sensible way to set
> > up YCbCr.
> >
> >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
> >> semiplanar, interleaved, etc)? I'm not really sure what you are
> >> referring to with the FB_AUX_* however.
> >
> > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
> > buffer memory.
> >
> > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
> > additional parameter (e.g. the interleave value for interleaved
> > bitplanes).
>
> Adding new standard values for these fb_fix_screeninfo fields would solve
> the issue for framebuffers which only support a single format.
I've never liked changing fixed screen information :-) It would be consistent
with the API though.
> If you have the need to switch
Yes I need that. This requires an API to set the mode through
fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
type_aux field). This would duplicate the information passed through
fb_var_screeninfo though. Do you think it's worth it ?
> I guess it would be a good idea to add a new flag to the vmode bitfield in
> fb_var_screeninfo which looks like a general purpose modifier for the
> videomode. You could than reuse any RGB-specific field you like to pass more
> information.
That looks good to me. The grayscale field could be reused to pass the 4CC.
> Maybe we should also use this chance to declare one of the fix_screeninfo
> reserved fields to be used for capability flags or an API version as we can
> assume that those are 0 (at least in sane drivers).
That's always good, although it's not a hard requirement for the purpose of
YUV support.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
* Linus Torvalds wrote: > PS. The voices in my head also tell me that the numbers are getting too big. > I may just call the thing 2.8.0. And I almost guarantee that this PS is going > to result in more discussion than the rest, but when the voices tell me to do > things, I listen. I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 18872] [RADEON:KMS:R100:SUSPEND] suspend to ram problems
https://bugzilla.kernel.org/show_bug.cgi?id=18872 Maté changed: What|Removed |Added CC||mate.ta...@gmail.com --- Comment #11 from Maté 2011-05-23 21:10:09 --- Same problem with vanilla 2.6.39 on debian testing. "At the STR process the backlight goes off shortly but remains lit during suspend. The screen goes black and stays black when out of suspend. Some flickering on/off when entering and leaving STR. There's short harddrive activity when coming out of suspend [1]. Also, suspend- and power-led blink/lit as they are supposed to. The box is then locked up, not reacting to keyboard input or even sysrq. Hard power off required." [1] not sure about this one There's a switch in /etc/default/acpi-support: #RADEON_LIGHT=true Commented or uncommented doesn't change the behavior during STR. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
i195 and boot freeze
since kernel .39 i can not boot, when kernel go to gmbus start the issue. I try capture a dump with kexec, but no success, so i have the idea to make video booting, kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem. http://www.vimeo.com/24138372 lspci -v 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Elitegroup Computer Systems Device 995b Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f800 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915 att -- yermandu ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > I really hope there's also a voice that tells you to wait until .42 before > > cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. I like that, it would make things much easier for me to keep track of stuff. > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. That sounds reasonable as well. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Standardize YUV support in the fbdev API
Hi Laurent,
On 05/23/2011 09:00 PM, Laurent Pinchart wrote:
On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
- Other solutions are possible, such as adding new ioctls. Those
solutions are more intrusive, and require larger changes to both
userspace and kernelspace code.
I'm against (ab)using the nonstd field (probably the only sane thing we can
do with it is declare it non-standard which interpretation is completely
dependent on the specific driver) or requiring previously unused fields to
have a special value so I'd like to suggest a different method:
I remembered an earlier discussion:
[ http://marc.info/?l=linux-fbdev&m=129896686208130&w=2 ]
On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
> On Tue, Mar 1, 2011 at 04:13, Damian wrote:
>> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
>>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
>>> FB_VISUAL_*
>>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
>>> fields are
>>> YCbCr instead of RGB.
>>> Depending on the frame buffer organization, you also need new
>>> FB_TYPE_*/FB_AUX_*
>>> types.
>>
>> I just wanted to clarify here. Is your comment about these new flags
>> in specific reference to this patch or to Magnus' "going forward"
>> comment? It
>
> About new flags.
>
>> seems like the beginnings of a method to standardize YCbCr support in
>> fbdev across all platforms.
>> Also, do I understand correctly that FB_VISUAL_ would specify the
>> colorspace
>
> FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
> to colors on the screen, so to me it looks like the sensible way to set
> up YCbCr.
>
>> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
>> semiplanar, interleaved, etc)? I'm not really sure what you are
>> referring to with the FB_AUX_* however.
>
> Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
> buffer memory.
>
> FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
> additional parameter (e.g. the interleave value for interleaved
> bitplanes).
Adding new standard values for these fb_fix_screeninfo fields would solve
the issue for framebuffers which only support a single format.
I've never liked changing fixed screen information :-) It would be consistent
with the API though.
Fixed does only mean that it can't be directly manipulated by applications. The
driver has to modify it anyway on about every mode change (line_length). Yes
perhaps some of these fields would be in var today and certainly others
shouldn't exist at all but I do not blame anyone for not being capable to look
into the future.
If you have the need to switch
Yes I need that. This requires an API to set the mode through
fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
type_aux field). This would duplicate the information passed through
fb_var_screeninfo though. Do you think it's worth it ?
I think it's more like a FB_VISUAL_FOURCC as you want to express how the color
<-> pixel mapping is. The FB_TYPE_* is more about whether pixel are packed or
represented as planes (the 2 format groups mentioned on fourcc.org).
That's certainly something I'd introduce as it would (hopefully) work to prevent
old applications which don't know your extension manipulating a FOURCC format
thinking that it is RGB.
So I think we should
fix.visual = FB_VISUAL_FOURCC;
fix.type = FB_TYPE_PACKED_PIXELS | FB_TYPE_PLANES; /* (?) */
or maybe add a FB_TYPE_FOURCC and rely only on the information in FOURCC (as
things like UYVY could become confusing as macropixel!=pixel)
I guess it would be a good idea to add a new flag to the vmode bitfield in
fb_var_screeninfo which looks like a general purpose modifier for the
videomode. You could than reuse any RGB-specific field you like to pass more
information.
That looks good to me. The grayscale field could be reused to pass the 4CC.
var.grayscale = ;
var.vmode = FB_VMODE_FOURCC;
and if this vmode flag is not set it means traditional mode (based on RGBA).
Maybe we should also use this chance to declare one of the fix_screeninfo
reserved fields to be used for capability flags or an API version as we can
assume that those are 0 (at least in sane drivers).
That's always good, although it's not a hard requirement for the purpose of
YUV support.
Sure. But it's good to let the application know whether you support the new
extension or whether you just ignore the flag. So I'm voting for a
fix.caps = FB_CAP_FOURCC;
Best regards,
Florian Tobias Schandinat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedeskto
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 4:33 PM, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >> >> I really hope there's also a voice that tells you to wait until .42 before >> cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. Could we set a goal of having 3.0 be the first release with a totally cleaned up ARM arch? That would give everyone a good target to work towards. -- Jon Smirl jonsm...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, 23 May 2011 19:17:21 -0400 Ted Ts'o wrote: > On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: > > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > > > I really hope there's also a voice that tells you to wait until .42 before > > > cutting 3.0.0! :-) > > > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > > not "3.0.0" - the stable team would get the third digit rather than > > the fourth one. > > If we change from 2.6.X to 3.X, then if we don't change anything else, > then successive stable release will cause the LINUX_VERSION_CODE to be > incremented. This isn't necessary bad, but it would be a different > from what we have now. It's just another little thing to break several scripts... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 --- Comment #2 from Benoit Jacob 2011-05-23 16:22:12 PDT --- (In reply to comment #1) > This is the same as bug 33188 isn't it? Looks like it (didn't know about the other bug), but this bug has more specific info, and also the testcase link is more specific. Close the other one as duplicate of this one (despite anachronism) ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Another advantage of switching numbering models (ie 3.0 instead of 2.8.x) would be that it would also make the "odd numbers are also numbers" transition much more natural. Because of our historical even/odd model, I wouldn't do a 2.7.x - there's just too much history of 2.1, 2.3, 2.5 being development trees. But if I do 3.0, then I'd be chucking that whole thing out the window, and the next release would be 3.1, 3.2, etc.. And then in another few years (probably before getting close to 3.40, so I'm not going to make a big deal of 3 = "third decade"), I'd just do 4.0 etc. Because all our releases are supposed to be stable releases these days, and if we get rid of one level of numbering, I feel perfectly fine with getting rid of the even/odd history too. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 05/23/2011 04:17 PM, Ted Ts'o wrote: > On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: >> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >>> >>> I really hope there's also a voice that tells you to wait until .42 before >>> cutting 3.0.0! :-) >> >> So I'm toying with 3.0 (and in that case, it really would be "3.0", >> not "3.0.0" - the stable team would get the third digit rather than >> the fourth one. > > If we change from 2.6.X to 3.X, then if we don't change anything else, > then successive stable release will cause the LINUX_VERSION_CODE to be > incremented. This isn't necessary bad, but it would be a different > from what we have now. > That sounds like a good thing. -hpa ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Hi Linus, On 05/23/2011 04:33 PM, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >> >> I really hope there's also a voice that tells you to wait until .42 before >> cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. A few months ago, I briefly considered suggesting that the demise of the BKL would be a suitable milestone for the numbering shakeup. But I am a mere mortal lurker, and I remember past flame-fests this topic spawned. So I chickened out. As a small-scale linux evangelist, I would sure like to skip the explanation of the version numbers. Phil ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
* Linus Torvalds wrote: > Another advantage of switching numbering models (ie 3.0 instead of > 2.8.x) would be that it would also make the "odd numbers are also > numbers" transition much more natural. Yeah, it sounds really good to get rid of the (meanwhile) meaningless "2.6." prefix from our version code and iterate it in a more meaningful way. I suspect the stable team and distros will enjoy the more meaningful third digit as well: it will raise the perceived importance of stabilization and packaging work. Btw., we should probably remove the fourth (patch) level, otherwise distros might feel tempted to fill it in with their own patch-stack version number, which would result in confusing "3.3.1.5" meaning different things on different distros - while 3.3.1-5.rpm style of distro kernel package naming denotes the distro patch level more clearly. I don't think the odd/even history will linger too long: in practice we'll iterate through 3.1, 3.2, 3.3 and 3.4 rather quickly, in the first year, so any residual notion of stable/unstable will be gone within a few iterations. > Because of our historical even/odd model, I wouldn't do a 2.7.x - > there's just too much history of 2.1, 2.3, 2.5 being development > trees. But if I do 3.0, then I'd be chucking that whole thing out the > window, and the next release would be 3.1, 3.2, etc.. > > And then in another few years (probably before getting close to 3.40, > so I'm not going to make a big deal of 3 = "third decade"), I'd just > do 4.0 etc. Perhaps we could do 4.0 once the last bit of -rt hits upstream? /me ducks > Because all our releases are supposed to be stable releases these > days, and if we get rid of one level of numbering, I feel perfectly > fine with getting rid of the even/odd history too. They are very stable releases as far as i'm concerned - i can pretty confidently run and use -rc2 and better kernels on my boxes these days and could do so for the past few years. Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
* Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > I really hope there's also a voice that tells you to wait until .42 before > > cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. Also, in all fairness, we should probably display a certain amount of humility: while Linux has certainly reached milestones such as world domination (as far as large and small computers are concerned), so calling it 3.0 is a fair deal, we probably have to wait for version 42.0 before we can consider the Linux kernel to be the ultimate answer to life, universe and everything. Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #7 from William Pitcock 2011-05-23 21:29:45 PDT --- Created an attachment (id=47086) --> (https://bugs.freedesktop.org/attachment.cgi?id=47086) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #8 from William Pitcock 2011-05-23 21:31:43 PDT --- Created an attachment (id=47087) --> (https://bugs.freedesktop.org/attachment.cgi?id=47087) glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 William Pitcock changed: What|Removed |Added Attachment #47086|0 |1 is obsolete|| --- Comment #9 from William Pitcock 2011-05-23 21:40:50 PDT --- Created an attachment (id=47088) --> (https://bugs.freedesktop.org/attachment.cgi?id=47088) actual dmesg (copy and paste fail) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #10 from William Pitcock 2011-05-23 21:41:53 PDT --- Created an attachment (id=47089) --> (https://bugs.freedesktop.org/attachment.cgi?id=47089) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #11 from William Pitcock 2011-05-23 21:44:01 PDT --- glxinfo, dmesg and xorg log have been attached. KMS color tiling is disabled. color tiling is also disabled without KMS. enabling color tiling on DRI1 does not trigger the bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #3 from Michel D?nzer 2011-05-23 00:31:17 PDT --- Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex . Does running thread apply all bt full in gdb give backtraces for any other threads? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm
https://bugs.freedesktop.org/show_bug.cgi?id=36563 --- Comment #4 from Ernst Sj?strand 2011-05-23 01:18:46 PDT --- Yes, it's probably when a new window is created or similar. But just opening 100 gnome-terminals doesn't trigger it so it's not super easy to trigger. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] New: texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 Summary: texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1 Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: nenolod at systeminplace.net hi, i get texture corruption as seen in the attached screenshot when using dri2. when running more 3D intensive applications (like say, etracer), the texture corruption increases resulting in some graphics primitives not being rendered. this does not happen with DRI1, with DRI1, there is no corruption and all primitives are rendered as expected. this is on linux 2.6.38.6 with alpine patches, mesa 7.10.2 and xorg 1.10 with xf86-video-ati 6.14.1, libdrm 2.4.25 and uclibc 0.9.32-rc3 (also with alpine patches). there are some bugs that look similar to what i am seeing, but they are all marked RESOLVED, and none of them mention DRI2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #1 from William Pitcock 2011-05-23 02:00:48 PDT --- it seems that attachment sizes are limited. see http://nenolod.net/~nenolod/radeon-dri2-gltexture-corruption.png for an example of what i am seeing. i think this is due to incomplete writes to the card or perhaps an off-by-one of some kind. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #2 from William Pitcock 2011-05-23 02:36:47 PDT --- oh, i forgot to mention, this is on a dual radeon hd 4870 setup. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Standardize YUV support in the fbdev API
On Monday, May 23, 2011 13:55:21 Marek Szyprowski wrote: > Hello, > > On Wednesday, May 18, 2011 8:54 AM Hans Verkuil wrote: > > > On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: > > > On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart > > > wrote: > > > > I need to implement support for a YUV frame buffer in an fbdev driver. > > As the > > > > fbdev API doesn't support this out of the box, I've spent a couple of > > days > > > > reading fbdev (and KMS) code and thinking about how we could cleanly > > add YUV > > > > support to the API. I'd like to share my findings and thoughts, and > > hopefully > > > > receive some comments back. > > > > > > > > The terms 'format', 'pixel format', 'frame buffer format' and 'data > > format' > > > > will be used interchangeably in this e-mail. They all refer to the way > > pixels > > > > are stored in memory, including both the representation of a pixel as > > integer > > > > values and the layout of those integer values in memory. > > > > > > This is a great proposal. It was about time! > > > > > > > The third solution has my preference. Comments and feedback will be > > > > appreciated. I will then work on a proof of concept and submit patches. > > > > > > I also would prefer the third solution. I don't think there's much > > > difference from the user-space point of view, and a new ioctl would be > > > cleaner. Also the v4l2 fourcc's should do. > > > > I agree with this. > > > > We might want to take the opportunity to fix this section of the V4L2 Spec: > > > > http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb > > > > There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and > > should be removed. > > That's definitely true. I was confused at the beginning when I saw 2 > different tables describing the same pixel formats. > > I suspect many if not all V4L2 drivers are badly broken for > > big-endian systems and report the wrong pixel formats. > > > > Officially the pixel formats reflect the contents of the memory. But > > everything is swapped on a big endian system, so you are supposed to > > report a different pix format. > > I always thought that pix_format describes the layout of video data in > memory on byte level, which is exactly the same on both little- and big- > endian systems. Correct. > You can notice swapped data only if you access memory > by units larger than byte, like 16bit or 32bit integers. BTW - I would > really like to avoid little- and big- endian flame, but your statement > about 'everything is swapped on a big endian system' is completely > wrong. It is rather the characteristic of little-endian system not big > endian one if you display the content of the same memory first using > byte access and then using word/long access. You are correct, I wasn't thinking it through. > > I can't remember seeing any driver do that. Some have built-in swapping, > > though, and turn that on if needed. > > The drivers shouldn't do ANY byte swapping at all. Only tools that > extract pixel data with some 'accelerated' methods (like 32bit integer > casting and bit-level shifting) should be aware of endianess. > > > I really need to run some tests, but I've been telling myself this for > > years now :-( > > I've checked the BTTV board in my PowerMac/G4 and the display was > correct with xawtv. It is just a matter of selecting correct pix format > basing on the information returned by xsever. > > Best regards > Just forget my post (except for the part of cleaning up the tables :-) ). Regards, Hans
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #3 from Alex Deucher 2011-05-23 05:49:22 PDT --- Please attach your xorg log, dmesg output, and glxinfo output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Standardize YUV support in the fbdev API
Hello, On Wednesday, May 18, 2011 8:54 AM Hans Verkuil wrote: > On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: > > On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart > > wrote: > > > I need to implement support for a YUV frame buffer in an fbdev driver. > As the > > > fbdev API doesn't support this out of the box, I've spent a couple of > days > > > reading fbdev (and KMS) code and thinking about how we could cleanly > add YUV > > > support to the API. I'd like to share my findings and thoughts, and > hopefully > > > receive some comments back. > > > > > > The terms 'format', 'pixel format', 'frame buffer format' and 'data > format' > > > will be used interchangeably in this e-mail. They all refer to the way > pixels > > > are stored in memory, including both the representation of a pixel as > integer > > > values and the layout of those integer values in memory. > > > > This is a great proposal. It was about time! > > > > > The third solution has my preference. Comments and feedback will be > > > appreciated. I will then work on a proof of concept and submit patches. > > > > I also would prefer the third solution. I don't think there's much > > difference from the user-space point of view, and a new ioctl would be > > cleaner. Also the v4l2 fourcc's should do. > > I agree with this. > > We might want to take the opportunity to fix this section of the V4L2 Spec: > > http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb > > There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and > should be removed. That's definitely true. I was confused at the beginning when I saw 2 different tables describing the same pixel formats. I suspect many if not all V4L2 drivers are badly broken for > big-endian systems and report the wrong pixel formats. > > Officially the pixel formats reflect the contents of the memory. But > everything is swapped on a big endian system, so you are supposed to > report a different pix format. I always thought that pix_format describes the layout of video data in memory on byte level, which is exactly the same on both little- and big- endian systems. You can notice swapped data only if you access memory by units larger than byte, like 16bit or 32bit integers. BTW - I would really like to avoid little- and big- endian flame, but your statement about 'everything is swapped on a big endian system' is completely wrong. It is rather the characteristic of little-endian system not big endian one if you display the content of the same memory first using byte access and then using word/long access. > I can't remember seeing any driver do that. Some have built-in swapping, > though, and turn that on if needed. The drivers shouldn't do ANY byte swapping at all. Only tools that extract pixel data with some 'accelerated' methods (like 32bit integer casting and bit-level shifting) should be aware of endianess. > I really need to run some tests, but I've been telling myself this for > years now :-( I've checked the BTTV board in my PowerMac/G4 and the display was correct with xawtv. It is just a matter of selecting correct pix format basing on the information returned by xsever. Best regards -- Marek Szyprowski Samsung Poland R&D Center
[Bug 37471] Website with information about maintainers/developers
https://bugs.freedesktop.org/show_bug.cgi?id=37471 --- Comment #1 from Brian Paul 2011-05-23 07:49:02 PDT --- I think it would be hard to keep that info up to date. If you're wondering who's most recently been working on a particular driver, the best thing to do is check the git history. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #1 from Sven Arvidsson 2011-05-23 10:12:27 PDT --- This is the same as bug 33188 isn't it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #4 from Fredrik H?glund 2011-05-23 10:22:09 PDT --- Judging by the screenshot this may be a duplicate of bug 33824. The logout effect in KWin uses automatically generated mipmaps + LOD bias to blur all windows except the dialog in the center of the screenshot. Does the problem go away if you set ColorTiling to False in your xorg.conf file? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37513] New: WebGL in Chrome: BadDrawable
https://bugs.freedesktop.org/show_bug.cgi?id=37513 Summary: WebGL in Chrome: BadDrawable Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se When running part of the WebGL conformance test, buffer-preserve-test.html, this error is repeated on the terminal and Chrome later crashes: [10066:10066:23755423156:ERROR:x11_util.cc(862)] X Error detected: serial 111, error_code 9 (BadDrawable (invalid Pixmap or Window parameter)), request_code 137, minor_code 8 (DRI2SwapBuffers) Chrome needs to be run with --ignore-gpu-blacklist --enable-webgl System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: git-fd6f2d6 -- drm: 2.4.25 -- kernel: 2.6.39 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #5 from Tobias Jakobi 2011-05-23 10:31:38 PDT --- This is most likely _no_ duplicate, since tiling still has to be force on with an envvar. And I don't see this happening from the explanations in the initial post. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: fix typo in spread spectrum code
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 48f5ff0..ec84878 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -440,7 +440,7 @@ static void atombios_crtc_program_ss(struct drm_crtc *crtc,
case ATOM_PPLL_INVALID:
return;
}
- args.v2.ucEnable = enable;
+ args.v3.ucEnable = enable;
if ((ss->percentage == 0) || (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v3.ucEnable = ATOM_DISABLE;
} else if (ASIC_IS_DCE4(rdev)) {
--
1.7.1.1
[PATCH] drm/radeon/kms/cayman: fix typo in register mask
Noticed by Droste on IRC. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/nid.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index b2088c1..9736746 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -353,7 +353,7 @@ #defineMULTI_GPU_TILE_SIZE_MASK0x0300 #defineMULTI_GPU_TILE_SIZE_SHIFT 24 #defineROW_SIZE(x) ((x) << 28) -#defineROW_SIZE_MASK 0x3007 +#defineROW_SIZE_MASK 0x3000 #defineROW_SIZE_SHIFT 28 #defineNUM_LOWER_PIPES(x) ((x) << 30) #defineNUM_LOWER_PIPES_MASK0x4000 -- 1.7.1.1
(Short?) merge window reminder
So I've been busily merging stuff, and just wanted to send out a quick reminder that I warned people in the 39 announcement that this might be a slightly shorter merge window than usual, so that I can avoid having to make the -rc1 release from Japan using my slow laptop (doing "allyesconfig" builds on that thing really isn't in the cards, and I like to do those to verify things - even if we've already had a few cases where arch include differences made it less than effective in finding problems). And judging by the merge window so far, that early close (probably Sunday - I'll be on airplanes next Monday) looks rather likely. I already seem to have a fairly sizable portion of linux-next in my tree, and there haven't been any huge upsets. So anybody who was planning a last-minute "please pull" - this is a heads-up. Don't do it, you might miss the window entirely. Did I miss any major development mailing lists with stuff pending? Linus PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen.
(Short?) merge window reminder
On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I listen.
If you do this, I will buy you a bottle of whatever whiskey you want
that I can get my hands on in Tokyo next week.
{crosses fingers}
greg k-h
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #6 from William Pitcock 2011-05-23 12:45:35 PDT --- re: color tiling, i believe it is disabled by default, but i will try and see if that is the problem. i will also get dmesg / Xorg logs when i switch back over to DRI2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #10 from Benjamin Bellec 2011-05-23 13:12:37 PDT --- In fact, I have these 2 issues also with gallium-swrast. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
On Mon, 23 May 2011 21:25:25 +0200 (CEST) Thomas Gleixner wrote: > On Mon, 23 May 2011, Linus Torvalds wrote: > > PS. The voices in my head also tell me that the numbers are getting > > too big. I may just call the thing 2.8.0. And I almost guarantee that > > this PS is going to result in more discussion than the rest, but when > > the voices tell me to do things, I listen. > > So the voices tell you to avoid .42 ? They tell him to avoid the question to which 42 is the answer. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
(Short?) merge window reminder
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > I really hope there's also a voice that tells you to wait until .42 before > cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be "3.0", not "3.0.0" - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying "we're about to start the third decade" works as well as any other excuse. But we'll see. Linus
[RFC] Standardize YUV support in the fbdev API
Hi Florian,
On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
> On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > I need to implement support for a YUV frame buffer in an fbdev driver. As
> > the fbdev API doesn't support this out of the box, I've spent a couple
> > of days reading fbdev (and KMS) code and thinking about how we could
> > cleanly add YUV support to the API. I'd like to share my findings and
> > thoughts, and hopefully receive some comments back.
>
> Thanks. I think you did already a good job, hope we can get it done this
> time.
Thanks. I'll keep pushing then :-)
> > Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share
> > data and buffers between those subsystems, and the planned use of V4L2
> > FCCs in the KMS overlay API, I believe using V4L2 FCCs to identify fbdev
> > formats would be a wise decision.
>
> I agree.
There seems to be a general agreement on this, so I'll consider this settled.
> > To select a frame buffer YUV format, the fb_var_screeninfo structure will
> > need to be extended with a format field. The fbdev API and ABI must not
> > be broken, which prevents us from changing the current structure layout
> > and replacing the existing format selection mechanism (through the red,
> > green, blue and alpha bitfields) completely.
>
> I agree.
>
> > - Other solutions are possible, such as adding new ioctls. Those
> > solutions are more intrusive, and require larger changes to both
> > userspace and kernelspace code.
>
> I'm against (ab)using the nonstd field (probably the only sane thing we can
> do with it is declare it non-standard which interpretation is completely
> dependent on the specific driver) or requiring previously unused fields to
> have a special value so I'd like to suggest a different method:
>
> I remembered an earlier discussion:
> [ http://marc.info/?l=linux-fbdev&m=129896686208130&w=2 ]
>
> On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
> > On Tue, Mar 1, 2011 at 04:13, Damian wrote:
> >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
> >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
> >>> FB_VISUAL_*
> >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
> >>> fields are
> >>> YCbCr instead of RGB.
> >>> Depending on the frame buffer organization, you also need new
> >>> FB_TYPE_*/FB_AUX_*
> >>> types.
> >>
> >> I just wanted to clarify here. Is your comment about these new flags
> >> in specific reference to this patch or to Magnus' "going forward"
> >> comment? It
> >
> > About new flags.
> >
> >> seems like the beginnings of a method to standardize YCbCr support in
> >> fbdev across all platforms.
> >> Also, do I understand correctly that FB_VISUAL_ would specify the
> >> colorspace
> >
> > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
> > to colors on the screen, so to me it looks like the sensible way to set
> > up YCbCr.
> >
> >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
> >> semiplanar, interleaved, etc)? I'm not really sure what you are
> >> referring to with the FB_AUX_* however.
> >
> > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
> > buffer memory.
> >
> > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
> > additional parameter (e.g. the interleave value for interleaved
> > bitplanes).
>
> Adding new standard values for these fb_fix_screeninfo fields would solve
> the issue for framebuffers which only support a single format.
I've never liked changing fixed screen information :-) It would be consistent
with the API though.
> If you have the need to switch
Yes I need that. This requires an API to set the mode through
fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
type_aux field). This would duplicate the information passed through
fb_var_screeninfo though. Do you think it's worth it ?
> I guess it would be a good idea to add a new flag to the vmode bitfield in
> fb_var_screeninfo which looks like a general purpose modifier for the
> videomode. You could than reuse any RGB-specific field you like to pass more
> information.
That looks good to me. The grayscale field could be reused to pass the 4CC.
> Maybe we should also use this chance to declare one of the fix_screeninfo
> reserved fields to be used for capability flags or an API version as we can
> assume that those are 0 (at least in sane drivers).
That's always good, although it's not a hard requirement for the purpose of
YUV support.
--
Regards,
Laurent Pinchart
(Short?) merge window reminder
* Linus Torvalds wrote: > PS. The voices in my head also tell me that the numbers are getting too big. > I may just call the thing 2.8.0. And I almost guarantee that this PS is going > to result in more discussion than the rest, but when the voices tell me to do > things, I listen. I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) Ingo
[Bug 18872] [RADEON:KMS:R100:SUSPEND] suspend to ram problems
https://bugzilla.kernel.org/show_bug.cgi?id=18872 Mat? changed: What|Removed |Added CC||mate.taixi at gmail.com --- Comment #11 from Mat? 2011-05-23 21:10:09 --- Same problem with vanilla 2.6.39 on debian testing. "At the STR process the backlight goes off shortly but remains lit during suspend. The screen goes black and stays black when out of suspend. Some flickering on/off when entering and leaving STR. There's short harddrive activity when coming out of suspend [1]. Also, suspend- and power-led blink/lit as they are supposed to. The box is then locked up, not reacting to keyboard input or even sysrq. Hard power off required." [1] not sure about this one There's a switch in /etc/default/acpi-support: #RADEON_LIGHT=true Commented or uncommented doesn't change the behavior during STR. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
i195 and boot freeze
since kernel .39 i can not boot, when kernel go to gmbus start the issue. I try capture a dump with kexec, but no success, so i have the idea to make video booting, kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem. http://www.vimeo.com/24138372 lspci -v 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Elitegroup Computer Systems Device 995b Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f800 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915 att -- yermandu
(Short?) merge window reminder
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > I really hope there's also a voice that tells you to wait until .42 before > > cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. I like that, it would make things much easier for me to keep track of stuff. > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. That sounds reasonable as well. greg k-h
[RFC] Standardize YUV support in the fbdev API
Hi Laurent,
On 05/23/2011 09:00 PM, Laurent Pinchart wrote:
> On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
>> On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
>>> - Other solutions are possible, such as adding new ioctls. Those
>>> solutions are more intrusive, and require larger changes to both
>>> userspace and kernelspace code.
>>
>> I'm against (ab)using the nonstd field (probably the only sane thing we can
>> do with it is declare it non-standard which interpretation is completely
>> dependent on the specific driver) or requiring previously unused fields to
>> have a special value so I'd like to suggest a different method:
>>
>> I remembered an earlier discussion:
>> [ http://marc.info/?l=linux-fbdev&m=129896686208130&w=2 ]
>>
>> On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
>> > On Tue, Mar 1, 2011 at 04:13, Damian wrote:
>> >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
>> >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
>> >>> FB_VISUAL_*
>> >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
>> >>> fields are
>> >>> YCbCr instead of RGB.
>> >>> Depending on the frame buffer organization, you also need new
>> >>> FB_TYPE_*/FB_AUX_*
>> >>> types.
>> >>
>> >> I just wanted to clarify here. Is your comment about these new flags
>> >> in specific reference to this patch or to Magnus' "going forward"
>> >> comment? It
>> >
>> > About new flags.
>> >
>> >> seems like the beginnings of a method to standardize YCbCr support in
>> >> fbdev across all platforms.
>> >> Also, do I understand correctly that FB_VISUAL_ would specify the
>> >> colorspace
>> >
>> > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
>> > to colors on the screen, so to me it looks like the sensible way to set
>> > up YCbCr.
>> >
>> >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
>> >> semiplanar, interleaved, etc)? I'm not really sure what you are
>> >> referring to with the FB_AUX_* however.
>> >
>> > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
>> > buffer memory.
>> >
>> > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
>> > additional parameter (e.g. the interleave value for interleaved
>> > bitplanes).
>>
>> Adding new standard values for these fb_fix_screeninfo fields would solve
>> the issue for framebuffers which only support a single format.
>
> I've never liked changing fixed screen information :-) It would be consistent
> with the API though.
Fixed does only mean that it can't be directly manipulated by applications. The
driver has to modify it anyway on about every mode change (line_length). Yes
perhaps some of these fields would be in var today and certainly others
shouldn't exist at all but I do not blame anyone for not being capable to look
into the future.
>> If you have the need to switch
>
> Yes I need that. This requires an API to set the mode through
> fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
>
> A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
> exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
> type_aux field). This would duplicate the information passed through
> fb_var_screeninfo though. Do you think it's worth it ?
I think it's more like a FB_VISUAL_FOURCC as you want to express how the color
<-> pixel mapping is. The FB_TYPE_* is more about whether pixel are packed or
represented as planes (the 2 format groups mentioned on fourcc.org).
That's certainly something I'd introduce as it would (hopefully) work to
prevent
old applications which don't know your extension manipulating a FOURCC format
thinking that it is RGB.
So I think we should
fix.visual = FB_VISUAL_FOURCC;
fix.type = FB_TYPE_PACKED_PIXELS | FB_TYPE_PLANES; /* (?) */
or maybe add a FB_TYPE_FOURCC and rely only on the information in FOURCC (as
things like UYVY could become confusing as macropixel!=pixel)
>> I guess it would be a good idea to add a new flag to the vmode bitfield in
>> fb_var_screeninfo which looks like a general purpose modifier for the
>> videomode. You could than reuse any RGB-specific field you like to pass more
>> information.
>
> That looks good to me. The grayscale field could be reused to pass the 4CC.
var.grayscale = ;
var.vmode = FB_VMODE_FOURCC;
and if this vmode flag is not set it means traditional mode (based on RGBA).
>> Maybe we should also use this chance to declare one of the fix_screeninfo
>> reserved fields to be used for capability flags or an API version as we can
>> assume that those are 0 (at least in sane drivers).
>
> That's always good, although it's not a hard requirement for the purpose of
> YUV support.
Sure. But it's good to let the application know whether you support the new
extension or whether you just ignore the flag. So I'm voting for a
fix
(Short?) merge window reminder
On Mon, May 23, 2011 at 4:33 PM, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >> >> I really hope there's also a voice that tells you to wait until .42 before >> cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. Could we set a goal of having 3.0 be the first release with a totally cleaned up ARM arch? That would give everyone a good target to work towards. -- Jon Smirl jonsmirl at gmail.com
(Short?) merge window reminder
On Mon, 23 May 2011 19:17:21 -0400 Ted Ts'o wrote: > On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: > > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > > > I really hope there's also a voice that tells you to wait until .42 before > > > cutting 3.0.0! :-) > > > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > > not "3.0.0" - the stable team would get the third digit rather than > > the fourth one. > > If we change from 2.6.X to 3.X, then if we don't change anything else, > then successive stable release will cause the LINUX_VERSION_CODE to be > incremented. This isn't necessary bad, but it would be a different > from what we have now. It's just another little thing to break several scripts... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 --- Comment #2 from Benoit Jacob 2011-05-23 16:22:12 PDT --- (In reply to comment #1) > This is the same as bug 33188 isn't it? Looks like it (didn't know about the other bug), but this bug has more specific info, and also the testcase link is more specific. Close the other one as duplicate of this one (despite anachronism) ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
Another advantage of switching numbering models (ie 3.0 instead of 2.8.x) would be that it would also make the "odd numbers are also numbers" transition much more natural. Because of our historical even/odd model, I wouldn't do a 2.7.x - there's just too much history of 2.1, 2.3, 2.5 being development trees. But if I do 3.0, then I'd be chucking that whole thing out the window, and the next release would be 3.1, 3.2, etc.. And then in another few years (probably before getting close to 3.40, so I'm not going to make a big deal of 3 = "third decade"), I'd just do 4.0 etc. Because all our releases are supposed to be stable releases these days, and if we get rid of one level of numbering, I feel perfectly fine with getting rid of the even/odd history too. Linus
(Short?) merge window reminder
On 05/23/2011 04:17 PM, Ted Ts'o wrote: > On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: >> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >>> >>> I really hope there's also a voice that tells you to wait until .42 before >>> cutting 3.0.0! :-) >> >> So I'm toying with 3.0 (and in that case, it really would be "3.0", >> not "3.0.0" - the stable team would get the third digit rather than >> the fourth one. > > If we change from 2.6.X to 3.X, then if we don't change anything else, > then successive stable release will cause the LINUX_VERSION_CODE to be > incremented. This isn't necessary bad, but it would be a different > from what we have now. > That sounds like a good thing. -hpa
(Short?) merge window reminder
Hi Linus, On 05/23/2011 04:33 PM, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >> >> I really hope there's also a voice that tells you to wait until .42 before >> cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. A few months ago, I briefly considered suggesting that the demise of the BKL would be a suitable milestone for the numbering shakeup. But I am a mere mortal lurker, and I remember past flame-fests this topic spawned. So I chickened out. As a small-scale linux evangelist, I would sure like to skip the explanation of the version numbers. Phil
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #7 from William Pitcock 2011-05-23 21:29:45 PDT --- Created an attachment (id=47086) --> (https://bugs.freedesktop.org/attachment.cgi?id=47086) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #8 from William Pitcock 2011-05-23 21:31:43 PDT --- Created an attachment (id=47087) --> (https://bugs.freedesktop.org/attachment.cgi?id=47087) glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 William Pitcock changed: What|Removed |Added Attachment #47086|0 |1 is obsolete|| --- Comment #9 from William Pitcock 2011-05-23 21:40:50 PDT --- Created an attachment (id=47088) --> (https://bugs.freedesktop.org/attachment.cgi?id=47088) actual dmesg (copy and paste fail) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #10 from William Pitcock 2011-05-23 21:41:53 PDT --- Created an attachment (id=47089) --> (https://bugs.freedesktop.org/attachment.cgi?id=47089) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #11 from William Pitcock 2011-05-23 21:44:01 PDT --- glxinfo, dmesg and xorg log have been attached. KMS color tiling is disabled. color tiling is also disabled without KMS. enabling color tiling on DRI1 does not trigger the bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
On Mon, 23 May 2011, Linus Torvalds wrote: > PS. The voices in my head also tell me that the numbers are getting > too big. I may just call the thing 2.8.0. And I almost guarantee that > this PS is going to result in more discussion than the rest, but when > the voices tell me to do things, I listen. So the voices tell you to avoid .42 ? Thanks, tglx
(Short?) merge window reminder
On 5/23/11, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: >> >> I really hope there's also a voice that tells you to wait until .42 before >> cutting 3.0.0! :-) I think, the best time for this, after reorganize the ARM arch folder / tree. > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. > > But we'll see. > >Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
(Short?) merge window reminder
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > > I really hope there's also a voice that tells you to wait until .42 before > > cutting 3.0.0! :-) > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > not "3.0.0" - the stable team would get the third digit rather than > the fourth one. If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the LINUX_VERSION_CODE to be incremented. This isn't necessary bad, but it would be a different from what we have now. - Ted
(Short?) merge window reminder
On Mon, May 23, 2011 at 01:21:26PM -0700, Randy Dunlap wrote: > > They tell him to avoid the question to which 42 is the answer. What 2.6 Linux kernel version was the last before 3.0? -- Steve
(Short?) merge window reminder
On Mon, May 23, 2011 at 03:21:21PM -0700, Greg KH wrote: > On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: > > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote: > > > I really hope there's also a voice that tells you to wait until .42 before > > > cutting 3.0.0! :-) > > > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > > not "3.0.0" - the stable team would get the third digit rather than > > the fourth one. > > I like that, it would make things much easier for me to keep track of > stuff. As long as 3.14 turns into a long-term support kernel and gets up to 159 ... In all serious, I'm very supportive of this move. I'm heartily sick of people claiming "we have version 2.6 support" when they really mean they haven't updated since version 2.6.9. Yeah, congratulations, you're seven years out of date. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
