[Bug 14799] [i915 sRGB texture] sRGB texture enabled but not actually working
http://bugs.freedesktop.org/show_bug.cgi?id=14799 Shuang He <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from Shuang He <[EMAIL PROTECTED]> 2008-03-07 21:05:23 PST --- verified, thanks, krh -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14799] [i915 sRGB texture] sRGB texture enabled but not actually working
http://bugs.freedesktop.org/show_bug.cgi?id=14799 Shuang He <[EMAIL PROTECTED]> changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Shuang He <[EMAIL PROTECTED]> 2008-03-07 21:05:05 PST --- it's fixed -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 Julien Cristau <[EMAIL PROTECTED]> changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | QAContact||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 14840] radeon 60 wakeups after resume
On Tue, 3 Nov 2026 06:25:38 + Jose Rodriguez <[EMAIL PROTECTED]> wrote: > On Fri, 7 Mar 2008 11:28:17 -0800 (PST) > [EMAIL PROTECTED] wrote: > > > http://bugs.freedesktop.org/show_bug.cgi?id=14840 > > > > --- Comment #3 from Alex Deucher <[EMAIL PROTECTED]> 2008-03-07 > > 11:28:16 PST --- does this patch help: > > http://www.botchco.com/alex/xorg/entervt.diff Oops, it seems that my first answer didn't get through. Yes, it works well now. I experienced some screen corruption with some application though, let me have this opened one more day to double check. Thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: latest xf86-video-ati breaks vt-switch/suspend/hibernate
Hi, > Any chance you could use git bisect to track down which change caused > the regression? Well after a ton of reboots (my poor laptop!)... master~30 ~20 ~19 ~18 = ok master ~17 ~15 ~10 = crash on resume, requires reboot master = fails to even start X, requires reboot git bisect gives: dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 is first bad commit commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 Author: Alex Deucher <[EMAIL PROTECTED](none)> Date: Sat Mar 1 16:23:51 2008 -0500 RADEON: memmap rework 1 Don't restore memmap regs on every mode switch. Just do memmap save/restore/setup on server start and VT switch. :04 04 18282e19fca68b7c5313b2cfcf8963fc6f7eb406 b7fd89d7822cecf666de7b7b45e8cf0dbc2dbc7e M src > Does reverting: a0a73208a21546ac120fb9a463261836c9ea7b55 help? Nope, this gave the same result as git master, ie a black screen when starting X, pressing ctrl-alt-backspace eventually killed something as I get the acpi messages. But I cannot get back to a VT and need to reboot. Alec - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14840] radeon 60 wakeups after resume
http://bugs.freedesktop.org/show_bug.cgi?id=14840 --- Comment #3 from Alex Deucher <[EMAIL PROTECTED]> 2008-03-07 11:28:16 PST --- does this patch help: http://www.botchco.com/alex/xorg/entervt.diff -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: latest xf86-video-ati breaks vt-switch/suspend/hibernate
On Thu, Mar 6, 2008 at 11:12 PM, Alec Robertson <[EMAIL PROTECTED]> wrote: > Hi, > > > > Any chance you could use git bisect to track down which change caused > > the regression? > > Well after a ton of reboots (my poor laptop!)... > > master~30 ~20 ~19 ~18 = ok > master ~17 ~15 ~10 = crash on resume, requires reboot > master = fails to even start X, requires reboot > > git bisect gives: > > dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 is first bad commit > commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 > Author: Alex Deucher <[EMAIL PROTECTED](none)> > Date: Sat Mar 1 16:23:51 2008 -0500 > > RADEON: memmap rework 1 > > Don't restore memmap regs on every mode switch. > Just do memmap save/restore/setup on server start and VT switch. > > :04 04 18282e19fca68b7c5313b2cfcf8963fc6f7eb406 > b7fd89d7822cecf666de7b7b45e8cf0dbc2dbc7e M src > > > Does reverting: a0a73208a21546ac120fb9a463261836c9ea7b55 help? > > Nope, this gave the same result as git master, ie a black screen when > starting X, pressing ctrl-alt-backspace eventually killed something as I > get the acpi messages. But I cannot get back to a VT and need to reboot. I have the same laptop, but unfortunately, I can't reproduce the problem. Does this patch help: http://www.botchco.com/alex/xorg/entervt.diff Alex - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14799] [i915 sRGB texture] sRGB texture enabled but not actually working
http://bugs.freedesktop.org/show_bug.cgi?id=14799 Kristian Høgsberg <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Kristian Høgsberg <[EMAIL PROTECTED]> 2008-03-07 10:48:42 PST --- Just committed this: commit 1e6943cf5592186c3721dfefbdcf1a519a79bd8f Author: Kristian Høgsberg <[EMAIL PROTECTED]> Date: Fri Mar 7 13:45:09 2008 -0500 [intel] Only enable GL_EXT_texture_sRGB on i965. Fixes #14799. Should fix this issue. There may be similar problems with GL_NV_point_sprite, GL_ARB_texture_non_power_of_two, GL_NV_texture_rectangle, GL_EXT_texture_rectangle, GL_ARB_point_sprite, GL_ARB_point_parameters, and GL_EXT_blend_logic_op, though I do think i915 supports those. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
http://wiki.x.org/wiki/Development/git updated
I found myself pointing people at krh's blog post on building the stack a lot recently, so I figured it should be made into an x.org wiki page. We already had a git development guide started, so I updated it based on krh's guide and a couple of the replies in his blog. Please give it a try and update it as needed (it could use a little beautifying, for example adding links for the various sections), and is missing proto & library build info, as well as a Gallium build guide, but it should be useful as-is... Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & QWS
On Friday, March 07, 2008 1:21 am Tom Cooksey wrote: > I'm a developer working on getting OpenGL ES working with QWS - the window > system built into Qt/Embedded. That is, Trolltech's own windowing system, > completely independent of X. The typical hardware we're working with is > PowerVR MBX, an OpenGL ES 1.1 complient device. We have also played with > ATI mobile chipsets. One thing all these devices have in common is rubbish > (IMO), closed source drivers. The only API we have for them is EGL, the > only on-screen surface is the entire display. > > While we are continuing development with these devices, I'm very keen to > develop a proof-of-concept driver using an open source desktop OpenGL > implementation. I want to show people what can be done with decent (& open) > drivers. Great, that's one of the goals we had in mind when changing the DRM recently. There's actually some standalone OpenGL code in the Mesa tree that can be used as a starting point (EGL & miniglx, two separate ways of doing that). > The first step I'd like to make is to just get something on the screen. I > was wondering if it's possible to use DRM to just map the framebuffer into > a user process's address space and use it like we would use the LinuxFB > device? Or do modern frame buffer drivers use the DRM themselves to do > this? Yeah, that should be doable with the current code on Intel & ATI devices. You'll have to allocate a new buffer object for your front buffer, then use it to set a new mode. We'd really like to hear any feedback you have about the interfaces and design; given that what you're doing is something we'd really like to support, we want to make sure we get it right before it gets pushed upstream into Linux and set in stone. Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14507] 855GM Suspend bug
http://bugs.freedesktop.org/show_bug.cgi?id=14507 --- Comment #14 from Alexey Kuznetsov <[EMAIL PROTECTED]> 2008-03-07 03:56:33 PST --- Same problem -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM & QWS
On Fri, 7 Mar 2008 10:21:28 +0100 Tom Cooksey <[EMAIL PROTECTED]> wrote: > Hi, > > I'm a developer working on getting OpenGL ES working with QWS - the window > system > built into Qt/Embedded. That is, Trolltech's own windowing system, completely > independent of X. The typical hardware we're working with is PowerVR MBX, an > OpenGL ES 1.1 complient device. We have also played with ATI mobile chipsets. > One > thing all these devices have in common is rubbish (IMO), closed source > drivers. The only > API we have for them is EGL, the only on-screen surface is the entire display. > > While we are continuing development with these devices, I'm very keen to > develop a > proof-of-concept driver using an open source desktop OpenGL implementation. I > want > to show people what can be done with decent (& open) drivers. > > I'm pretty new to X, DRI & associated code bases but have spent the last few > months > reading documentation & code, trying to understand how everything works > together. > I think I've now got to a stage where I've read everything I could find and > need some > help. > > The effect I'm looking for is iPhone/Compiz style window composition. We have > this > already, but the problem is that the drivers are designed for a single process > accessing the hardware at a time. This is fine if there's only a single > process (in QWS, > the window system is a shared library which is loaded by the first > application to be > launched). All the windows can be drawn into off-screen pbuffers and then > used as > textures to be rendered onto the screen. The problem comes when there are > multiple > processes. Our current solution is to get the client processes to use our > raster paint > engine to render into shared memory, which the server then uploads as a > texture. > As you can imagine, this is *SLOW*. It also doesn't allow client processes to > use > OpenGL themselves - something we really want to have. > > What we want to do is use our OpenGL paint engine (or, even better, an OpenVG > paint engine - which maps much better to Qt's painter API) in the client > processes. > The client processes render both 2D windows and OpenGL calls to off-screen > buffers, which the server can use as textures. We'd also like video to be > handled in > a similar way (VAAPI?). > > >From what I've read, AIGLX allows compiz to composite OpenGL window surfaces > because it's the X server which does the rendering. I.e. X clients serialize > OpenGL > commands and send them to the server via GLX. While we could do this too, (and > will probably have to do this for nasty closed source OpenGL ES drivers), I > stumbled upon this: > > http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html > > What I'm hoping to do is bring together all the very fine work done in the > last few > years. What I'm stuck on is how everything is going to hang together. This is > what > I have so far (most of which is probably wrong, so please correct): > > Write a QWS driver where the server opens the framebuffer using DRM > Modesetting. > The server also initializes the DRM. QWS clients render into off-screen > buffers > (pbuffers or Framebuffer objects?) using OpenGL (Mesa/Gallium?). The QWS > client > then magicaly gets the DRM ID of the off-screen buffer (Is there a 1:1 > relationship > between a DRM buffer and a framebuffer object's color buffer?). The clients > then > send that DRM ID to the server. The server then somehow magically tells > mesa/gallium about the buffer which is then (also magically) mapped to a > texture > name/ID and used as a texture to be drawn into the framebuffer. > > Obviously, I still have a lot to learn. :-D > > The first step I'd like to make is to just get something on the screen. I was > wondering if it's possible to use DRM to just map the framebuffer into a user > process's address space and use it like we would use the LinuxFB device? Or > do modern frame buffer drivers use the DRM themselves to do this? > > > Any/all comments, suggestions & insults are welcome. :-) > > > Cheers, > > Tom In drm tree you can find example on how to use drm modesetting (test directory). The drm modesetting interface is going under heavy change Dave, Jesse and Jakob are one working on that, so it's likely going to evolve a bit see http://dri.freedesktop.org/wiki/DrmModesetting for an overview of what the current aim is. Once you got your app in charge of modesetting, then you can work on winsys gallium driver. winsys driver is the part which interface with your windowing system. As you are not using X you need to do your own winsys, but this will likely end up being a lot of cut & paste. What you also need is somethings like DRI2 ie passing drm object id is not enough for compositor. DRM buffer object don't have information on the size or format or data they containt. So you need to pass BO ID between your server and your client through somethings like DRI2 where along
DRM & QWS
Hi, I'm a developer working on getting OpenGL ES working with QWS - the window system built into Qt/Embedded. That is, Trolltech's own windowing system, completely independent of X. The typical hardware we're working with is PowerVR MBX, an OpenGL ES 1.1 complient device. We have also played with ATI mobile chipsets. One thing all these devices have in common is rubbish (IMO), closed source drivers. The only API we have for them is EGL, the only on-screen surface is the entire display. While we are continuing development with these devices, I'm very keen to develop a proof-of-concept driver using an open source desktop OpenGL implementation. I want to show people what can be done with decent (& open) drivers. I'm pretty new to X, DRI & associated code bases but have spent the last few months reading documentation & code, trying to understand how everything works together. I think I've now got to a stage where I've read everything I could find and need some help. The effect I'm looking for is iPhone/Compiz style window composition. We have this already, but the problem is that the drivers are designed for a single process accessing the hardware at a time. This is fine if there's only a single process (in QWS, the window system is a shared library which is loaded by the first application to be launched). All the windows can be drawn into off-screen pbuffers and then used as textures to be rendered onto the screen. The problem comes when there are multiple processes. Our current solution is to get the client processes to use our raster paint engine to render into shared memory, which the server then uploads as a texture. As you can imagine, this is *SLOW*. It also doesn't allow client processes to use OpenGL themselves - something we really want to have. What we want to do is use our OpenGL paint engine (or, even better, an OpenVG paint engine - which maps much better to Qt's painter API) in the client processes. The client processes render both 2D windows and OpenGL calls to off-screen buffers, which the server can use as textures. We'd also like video to be handled in a similar way (VAAPI?). >From what I've read, AIGLX allows compiz to composite OpenGL window surfaces because it's the X server which does the rendering. I.e. X clients serialize OpenGL commands and send them to the server via GLX. While we could do this too, (and will probably have to do this for nasty closed source OpenGL ES drivers), I stumbled upon this: http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html What I'm hoping to do is bring together all the very fine work done in the last few years. What I'm stuck on is how everything is going to hang together. This is what I have so far (most of which is probably wrong, so please correct): Write a QWS driver where the server opens the framebuffer using DRM Modesetting. The server also initializes the DRM. QWS clients render into off-screen buffers (pbuffers or Framebuffer objects?) using OpenGL (Mesa/Gallium?). The QWS client then magicaly gets the DRM ID of the off-screen buffer (Is there a 1:1 relationship between a DRM buffer and a framebuffer object's color buffer?). The clients then send that DRM ID to the server. The server then somehow magically tells mesa/gallium about the buffer which is then (also magically) mapped to a texture name/ID and used as a texture to be drawn into the framebuffer. Obviously, I still have a lot to learn. :-D The first step I'd like to make is to just get something on the screen. I was wondering if it's possible to use DRM to just map the framebuffer into a user process's address space and use it like we would use the LinuxFB device? Or do modern frame buffer drivers use the DRM themselves to do this? Any/all comments, suggestions & insults are welcome. :-) Cheers, Tom - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tracked down a problem with memory validation
Thomas Hellström wrote: > Dave Airlie wrote: > >> Hi Thomas, >> >> Okay I've come across a problem in the kernel memory validaton that >> I'm not sure how to solve, >> >> The sequence of events is something like.. >> >> a) allocate frontbuffer MEM_LOCAL. >> b) setstatus into MEM_VRAM | MEM_TT >> c) emit a relocation in a batchbuffer to its BO for only MEM_TT >> (possibly a bug - need to setup better) >> Well, even if it's a bug, the kernel should obviously stop of NO_EVICT buffers to submit relocations which cause them to be moved, and error in this case. I think I have a patch for that lying around somehere... /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tracked down a problem with memory validation
Dave Airlie wrote: > Hi Thomas, > > Okay I've come across a problem in the kernel memory validaton that > I'm not sure how to solve, > > The sequence of events is something like.. > > a) allocate frontbuffer MEM_LOCAL. > b) setstatus into MEM_VRAM | MEM_TT > c) emit a relocation in a batchbuffer to its BO for only MEM_TT > (possibly a bug - need to setup better) > d) submit batchbuffer. > > Now although what I may be doing is slightly wrong, what the bo mem > layer does it really wierd.. > > as drm_bo_mem_compat fails as the VRAM bit is left over, it calls into > the drm_bo_mem_space function > which allocates a chunk of TTM memory space for the frontbuffer again, > and again, and again, until I run out of aperture. > That's really odd. It shouldn't do that. Do you have a small test app? > Setting the flags on setstatus to MEM_TT, makes it work but I just > thought I raise the issue. > We should be hitting basically the same code paths, but clearly something is wrong. /Thomas > Dave. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
