[ANNOUNCE] xf86-video-intel 2.21.9
Release 2.21.9 (2013-06-06) === Consolidating the copy-on-write support, hopefully cleaning up the last of the regressions. * Restore vsync on textured videos. [regression from 2.21.8] https://bugs.freedesktop.org/show_bug.cgi?id=65048 * Fix incorrect ordering of possible_clones with certain outputs, which can lead to attempting to incorrectly clone 2 outputs and failing to light them up. [regression from 2.20.10] * Fix performance regression from not promoting large fills to the GPU [regression from 2.21.7] * Undo the pixmap clone before performing a DRI2CopyRegion [regression from 2.21.7] https://bugs.freedesktop.org/show_bug.cgi?id=65250 Complete list of changes since 2.21.8 - Chris Wilson (23): sna/video: Correct interpretation of 'sync' test: Add an easily visible tearing test for video playback sna: Call mode update after disabling outputs upon VT switch sna: Make the backend identifier more informative Add the known marketing names for the performance Haswell parts sna: Sanity check that CRTC / output combination is valid sna: Log which outputs are being configured during a modeset sna: Report allocations failures during Screen initialisation sna: Cleanup up error reporting after failure to init KMS interface sna: Assert that an existing scanout is the desired size sna: Restore GPU promotion for large fills sna: Compile fix for non-debug builds sna/dri: Reorder assert not to fail on a pageflip deferred to after a modeset sna: Prevent adding damage to an already all-damaged GPU bo sna: Add some more DBG hints to copy-on-write cloning sna/dri: Undo any COW before performing a copy with DRI2CopyRegion sna: Make copying the glyph size more compact sna: Always populate the CPU features string sna: Do not conflate ignoring an output with an allocation failure sna/video: Fix redundant initialisation of video-clip sna: Include the GT details in the backend name for a chipset sna: Only emit an error for terminal mmap failures 2.21.9 release Daniel Vetter (1): sna: fixup up possible_clones kms-X impedance mismatch Rodrigo Vivi (1): Add more correct names for Haswell. git tag: 2.21.9 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.9.tar.bz2 MD5: fd96651b0d90dc7e977b23fd54f2c3e8 xf86-video-intel-2.21.9.tar.bz2 SHA1: e2f0b75929ba90c0abdbe2233ecfb5b3ccefc323 xf86-video-intel-2.21.9.tar.bz2 SHA256: 1359cbc9e494a284faa52d1db83e7388cb8ab590b660e29e78e6e7f5ee7ff189 xf86-video-intel-2.21.9.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.9.tar.gz MD5: f56fc5a53d730c5b7a037cfce2b71196 xf86-video-intel-2.21.9.tar.gz SHA1: a7b6c36c84fb7336384bfffb6cfb3c8a4b5e6946 xf86-video-intel-2.21.9.tar.gz SHA256: 35690e66ed5a99864b66e7abd86ca4bb2b077949c5e0716a8bc03cbd12623a6a xf86-video-intel-2.21.9.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Help on under the hood article on why openSUSE xorg could did not default to vesa driver but instead loaded fbdev device limited to 800x600 in Hyper-V virtual machine
I am trying to analyse the Xorg.0.log in /var/log on an openSUSE 12.3 install in a Hyper-V virtual machine. CentOS 6.3 and Ubuntu 12.04 LTS both loaded fine, but for some reason the vesa driver for the virtualized graphics card (Microsoft graphics card) did not load only the primitive fbdev and fbdevhw device loaded, limiting the X screen to 800x600 mode. There is a fix a fellow on the openSUSE hardware forum suggested, but I wanted to create an article to address the whys and wherefores of why this happened to help people with the fix foremost, give a summary explanation secondly and then give and in-depth analysis of why it happened. So far, I have fumbled through the Xorg.0.log and done the best I could, but it is a work in progress. Any help with this article would be appreciated: http://www.sanbarcomputing.com/?p=2033 I am hoping it will not only educate me in the writing, but educate others interested in this subject and help those who need the fix as well. Thanks in advance! ** *Scott Sanbar, Chief Engineer, Sanbar Computing * scott.san...@gmail.com | http://www.sanbarcomputing.com | (405) 227-4724 Personal Blog: http://www.aeoril.com/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Current DRI3 specification
On 06/05/2013 06:20 PM, Keith Packard wrote:
* PGP Signed by an unknown key
James Jones jajo...@nvidia.com writes:
I read through this and the extension specification below. The DRI3
stuff doesn't directly affect our driver at the moment of course, but I
like the direction it's going and the proposed/implied interactions
between DRI3 and Present.
Thanks much for the review. I think the most relevant question for the
binary nVidia driver is whether you think you can do something similar
in terms of mapping your back buffers into X pixmaps for use by
Present.
Yeah, I think the semantics are compatible. We allocate these buffers
on the server-side, but I don't think that affects the interaction with
Present.
Oh, I'm curious if you think we should be mapping the OML_sync_control
UST/MSC/SBC triplet into Sync extension counters. It sure seems like a
natural fit to me, and would reduce the size of the Present extension
quite a bit.
I've never been fond of the OML triplet because the values don't
correspond well to the counters/clocks our HW has. However, it was
always the intent that there would be a bunch of external-event
triggered types of fences added via other extensions (trigger at a given
timer value, when a certain scanline is reached, triggered while in the
vblank region or a certain bracketed set of scanlines, etc.)
Perhaps rather than merge these into sync or present, there could be
small, separate extensions that introduce various new ways to create a
fence sync object with these properties. One such extension could
introduce the OML values either as a combined fence object, or as 3
separate objects. I had imagined the present operation would take an
arbitrary length ordered list of fence sync objects to wait for, which
would be passed down to drivers where they could be collapsed when
possible. For example, if the HW or kernel driver supports waiting for
the first vblank after a given timer value was reached as a single
operation, the fence sequence { TIMER, VBLANK } could be collapsed into
a single HW/kernel wait operation by the corresponding X driver.
Thanks,
-James
I read through your futex-based fence sync implementation notes as well.
Seems reasonable to me. I didn't try too hard to poke holes in it
though.
I've had a couple of other positive reviews of that code; obviously it's
going to take some actual failures before people figure out why it
doesn't work right :-)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Nomination for 1.14 branch: Only call xf86platformVTProbe() when it's defined
Hi, I would like to nominate the patch http://cgit.freedesktop.org/xorg/xserver/commit/?id=9878e097a7de2f86eff0dcfd9fe5d83b162197ec (Only call xf86platformVTProbe() when it's defined) for the 1.14 branch because it fixes a build regression that was introduced into the branch after 1.14.1. Best regards, Chí-Thanh Christopher Nguyễn ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2] libX11: check size of GetReqExtra after XFlush
Two users of GetReqExtra pass arbitrarily sized allocations from the
caller (ModMap and Host). Adjust _XGetRequest() (called by the GetReqExtra
macro) to double-check the requested length and invalidate req when this
happens. Users of GetReqExtra passing lengths greater than the Xlib buffer
size (normally 16K) now check req and fail if something has gone wrong.
Any other callers of GetReqExtra that do not check req for NULL
will experience this change, in the pathological case, as a NULL
dereference instead of a buffer overflow. This is an improvement, but
the documentation for GetReqExtra has been updated to reflect the need
to check the value of req after the call.
Prior version of this patch:
http://lists.x.org/archives/xorg-devel/2011-July/023936.html
Bug that manifested the problem:
https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/792628
Signed-off-by: Kees Cook k...@outflux.net
---
specs/libX11/AppC.xml | 4 +++-
src/Host.c| 8
src/ModMap.c | 4
src/XlibInt.c | 8
4 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/specs/libX11/AppC.xml b/specs/libX11/AppC.xml
index df25027..0b37048 100644
--- a/specs/libX11/AppC.xml
+++ b/specs/libX11/AppC.xml
@@ -2468,7 +2468,9 @@ which is the same as
functionGetReq/function
except that it takes an additional argument (the number of
extra bytes to allocate in the output buffer after the request structure).
-This number should always be a multiple of four.
+This number should always be a multiple of four. Note that it is possible
+for req to be set to NULL as a defensive measure if the requested length
+exceeds the Xlib's buffer size (normally 16K).
/para
/sect2
sect2 id=Variable_Length_Arguments
diff --git a/src/Host.c b/src/Host.c
index da9923a..da5e2f7 100644
--- a/src/Host.c
+++ b/src/Host.c
@@ -83,6 +83,10 @@ XAddHost (
LockDisplay(dpy);
GetReqExtra (ChangeHosts, length, req);
+if (!req) {
+ UnlockDisplay(dpy);
+ return 0;
+}
req-mode = HostInsert;
req-hostFamily = host-family;
req-hostLength = addrlen;
@@ -118,6 +122,10 @@ XRemoveHost (
LockDisplay(dpy);
GetReqExtra (ChangeHosts, length, req);
+if (!req) {
+ UnlockDisplay(dpy);
+ return 0;
+}
req-mode = HostDelete;
req-hostFamily = host-family;
req-hostLength = addrlen;
diff --git a/src/ModMap.c b/src/ModMap.c
index 5c5b426..f66e559 100644
--- a/src/ModMap.c
+++ b/src/ModMap.c
@@ -80,6 +80,10 @@ XSetModifierMapping(
LockDisplay(dpy);
GetReqExtra(SetModifierMapping, mapSize, req);
+if (!req) {
+ UnlockDisplay(dpy);
+ return 2;
+}
req-numKeyPerModifier = modifier_map-max_keypermod;
diff --git a/src/XlibInt.c b/src/XlibInt.c
index b06e57b..c3273a8 100644
--- a/src/XlibInt.c
+++ b/src/XlibInt.c
@@ -1733,6 +1733,14 @@ void *_XGetRequest(Display *dpy, CARD8 type, size_t len)
if (dpy-bufptr + len dpy-bufmax)
_XFlush(dpy);
+/* Request still too large, so do not allow it to overflow. */
+if (dpy-bufptr + len dpy-bufmax) {
+ fprintf(stderr,
+ Xlib: request %d length %zd would exceed buffer size.\n,
+ type, len);
+ /* Changes failure condition from overflow to NULL dereference. */
+ return NULL;
+}
if (len % 4)
fprintf(stderr,
--
1.8.1.2
--
Kees Cook@outflux.net
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xaw3d 0/2] Xaw3d build system
I'm inclined to push these, but they cause redefinition warnings during compilation: libtool: compile: ... -o .libs/AsciiText.o In file included from .../libXaw3d-/src/AsciiSink.c:50:0: ../config.h:90:0: warning: XAW_ARROW_SCROLLBARS redefined [enabled by default] #define XAW_ARROW_SCROLLBARS /**/ ^ command-line:0:0: note: this is the location of the previous definition In file included from .../libXaw3d-/src/AsciiSink.c:50:0: ../config.h:93:0: warning: XAW_GRAY_BLKWHT_STIPPLES redefined [enabled by default] #define XAW_GRAY_BLKWHT_STIPPLES /**/ ^ command-line:0:0: note: this is the location of the previous definition In file included from .../libXaw3d-/src/AsciiSink.c:50:0: ../config.h:96:0: warning: XAW_INTERNATIONALIZATION redefined [enabled by default] #define XAW_INTERNATIONALIZATION /**/ ^ command-line:0:0: note: this is the location of the previous definition In file included from .../libXaw3d-/src/AsciiSink.c:50:0: ../config.h:99:0: warning: XAW_MULTIPLANE_PIXMAPS redefined [enabled by default] #define XAW_MULTIPLANE_PIXMAPS /**/ ^ command-line:0:0: note: this is the location of the previous definition Since they are added to the .h file, perhaps they should be removed from XAW3D_CPPFLAGS and xaw3d.pc's Cflags section? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xaw3d 1/2] Fix --disable-feature options in configure
I did push this one, though, as 2c16f3221c15b88a1122c35c0b091e8fcc2523fe. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] libX11: check size of GetReqExtra after XFlush
On 06/ 6/13 10:40 AM, Kees Cook wrote:
Two users of GetReqExtra pass arbitrarily sized allocations from the
caller (ModMap and Host). Adjust _XGetRequest() (called by the GetReqExtra
macro) to double-check the requested length and invalidate req when this
happens. Users of GetReqExtra passing lengths greater than the Xlib buffer
size (normally 16K) now check req and fail if something has gone wrong.
An alternative would be to convert them to use Data instead of GetReqExtra()
as the requests like PutImage do that truly send arbitrarily large data to
the server, but I'm not sure it's worth it in these cases.
diff --git a/src/ModMap.c b/src/ModMap.c
index 5c5b426..f66e559 100644
--- a/src/ModMap.c
+++ b/src/ModMap.c
@@ -80,6 +80,10 @@ XSetModifierMapping(
LockDisplay(dpy);
GetReqExtra(SetModifierMapping, mapSize, req);
+if (!req) {
+ UnlockDisplay(dpy);
+ return 2;
Style nit, please return MappingFailed instead of the raw value. (I see
the comment above the function uses the raw values instead of the symbolic
names used in the man pages and server side code, which is unfortunate.)
+}
req-numKeyPerModifier = modifier_map-max_keypermod;
Since the protocol defines that as a single byte, we should probably reject
at the top of the function any modifier_map-max_keypermod 255, as otherwise
we send a packet to the X server with more data than expected, which it will
reject - and that limit would also keep the mapSize within the normal Xlib
buffer size. That doesn't need to be this patch though.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] libX11: check size of GetReqExtra after XFlush
It seems to me that the change to GetReqExtra should indeed be merged. I
think now we're just debating what to do with any possibly-hazardous
callers. Kees, perhaps you could split the patch?
Regarding the rest, I like Alan's comments, and would add:
On Jun 6, 2013 9:17 PM, Alan Coopersmith alan.coopersm...@oracle.com
wrote:
On 06/ 6/13 10:40 AM, Kees Cook wrote:
Two users of GetReqExtra pass arbitrarily sized allocations from the
caller (ModMap and Host). Adjust _XGetRequest() (called by the
GetReqExtra
macro) to double-check the requested length and invalidate req when
this
happens. Users of GetReqExtra passing lengths greater than the Xlib
buffer
size (normally 16K) now check req and fail if something has gone wrong.
An alternative would be to convert them to use Data instead of
GetReqExtra()
as the requests like PutImage do that truly send arbitrarily large data to
the server, but I'm not sure it's worth it in these cases.
Since the original bug report was about xhost failing on long hostnames,
maybe it actually is worthwhile to make the Host routines use Data?
diff --git a/src/ModMap.c b/src/ModMap.c
index 5c5b426..f66e559 100644
--- a/src/ModMap.c
+++ b/src/ModMap.c
@@ -80,6 +80,10 @@ XSetModifierMapping(
LockDisplay(dpy);
GetReqExtra(SetModifierMapping, mapSize, req);
+if (!req) {
+ UnlockDisplay(dpy);
+ return 2;
Style nit, please return MappingFailed instead of the raw value. (I see
the comment above the function uses the raw values instead of the symbolic
names used in the man pages and server side code, which is unfortunate.)
+}
req-numKeyPerModifier = modifier_map-max_keypermod;
Since the protocol defines that as a single byte, we should probably
reject
at the top of the function any modifier_map-max_keypermod 255, as
otherwise
we send a packet to the X server with more data than expected, which it
will
reject - and that limit would also keep the mapSize within the normal Xlib
buffer size. That doesn't need to be this patch though.
I like this plan. Is MappingFailed the right return value for an
out-of-range value?
Jamey
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:libXmu] Fix a const issue.
On 06/ 2/13 12:10 PM, Thomas Klausner wrote: --- src/StrToGrav.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com and pushed: To ssh://git.freedesktop.org/git/xorg/lib/libXmu 474d224..e46ecb4 master - master -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:mkfontscale 1/2] Protect config.h inclusion like usual.
On 06/ 2/13 12:16 PM, Thomas Klausner wrote: --- ident.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ident.c b/ident.c index bf54483..8addee7 100644 --- a/ident.c +++ b/ident.c @@ -47,7 +47,9 @@ and 0 if it should be processed normally. identifyBitmap is much faster than parsing the whole font. */ +#ifdef HAVE_CONFIG_H #include config.h +#endif #include stdlib.h #include string.h Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com and pushed: To ssh://git.freedesktop.org/git/xorg/app/mkfontscale 19e2cb7..f731c5c master - master -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:mkfontscale 2/2] Remove a couple of 'const' that aren't OK for the caller.
On 06/ 2/13 12:16 PM, Thomas Klausner wrote:
---
mkfontscale.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mkfontscale.c b/mkfontscale.c
index 53c5303..15efaac 100644
--- a/mkfontscale.c
+++ b/mkfontscale.c
@@ -60,7 +60,7 @@
#define QUOTE(x) #x
#define STRINGIFY(x) QUOTE(x)
-static const char *encodings_array[] =
+static char *encodings_array[] =
{ ascii-0,
iso8859-1, iso8859-2, iso8859-3, iso8859-4, iso8859-5,
iso8859-6, iso8859-6.8, iso8859-6.8x, iso8859-6.16,
@@ -79,7 +79,7 @@ static const char *encodings_array[] =
gb2312.1980-0, gb18030.2000-0, gb18030.2000-1,
ksc5601.1987-0, ksc5601.1992-3};
-static const char *extra_encodings_array[] =
+static char *extra_encodings_array[] =
{ iso10646-1, adobe-fontspecific, microsoft-symbol };
static ListPtr encodings, extra_encodings;
I'm not sure what the best thing to do is here - removing the const just
brings back all the warnings that we're using a non-const char * for all
those string literals, but since we pass the array to
ListPtr makeList(char **a, int n, ListPtr old, int begin);
we get complaints about passing a const to a function wanting non-const.
I started looking at changing the List functions to all use const char *,
but the xlfd lists pass dynamically allocated values to those and use
deepDestroyList() to free them, so this code just expects some lists to
have constant strings and some not to and to use the same functions
types for both, which is messy.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.21.9
Release 2.21.9 (2013-06-06) === Consolidating the copy-on-write support, hopefully cleaning up the last of the regressions. * Restore vsync on textured videos. [regression from 2.21.8] https://bugs.freedesktop.org/show_bug.cgi?id=65048 * Fix incorrect ordering of possible_clones with certain outputs, which can lead to attempting to incorrectly clone 2 outputs and failing to light them up. [regression from 2.20.10] * Fix performance regression from not promoting large fills to the GPU [regression from 2.21.7] * Undo the pixmap clone before performing a DRI2CopyRegion [regression from 2.21.7] https://bugs.freedesktop.org/show_bug.cgi?id=65250 Complete list of changes since 2.21.8 - Chris Wilson (23): sna/video: Correct interpretation of 'sync' test: Add an easily visible tearing test for video playback sna: Call mode update after disabling outputs upon VT switch sna: Make the backend identifier more informative Add the known marketing names for the performance Haswell parts sna: Sanity check that CRTC / output combination is valid sna: Log which outputs are being configured during a modeset sna: Report allocations failures during Screen initialisation sna: Cleanup up error reporting after failure to init KMS interface sna: Assert that an existing scanout is the desired size sna: Restore GPU promotion for large fills sna: Compile fix for non-debug builds sna/dri: Reorder assert not to fail on a pageflip deferred to after a modeset sna: Prevent adding damage to an already all-damaged GPU bo sna: Add some more DBG hints to copy-on-write cloning sna/dri: Undo any COW before performing a copy with DRI2CopyRegion sna: Make copying the glyph size more compact sna: Always populate the CPU features string sna: Do not conflate ignoring an output with an allocation failure sna/video: Fix redundant initialisation of video-clip sna: Include the GT details in the backend name for a chipset sna: Only emit an error for terminal mmap failures 2.21.9 release Daniel Vetter (1): sna: fixup up possible_clones kms-X impedance mismatch Rodrigo Vivi (1): Add more correct names for Haswell. git tag: 2.21.9 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.9.tar.bz2 MD5: fd96651b0d90dc7e977b23fd54f2c3e8 xf86-video-intel-2.21.9.tar.bz2 SHA1: e2f0b75929ba90c0abdbe2233ecfb5b3ccefc323 xf86-video-intel-2.21.9.tar.bz2 SHA256: 1359cbc9e494a284faa52d1db83e7388cb8ab590b660e29e78e6e7f5ee7ff189 xf86-video-intel-2.21.9.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.9.tar.gz MD5: f56fc5a53d730c5b7a037cfce2b71196 xf86-video-intel-2.21.9.tar.gz SHA1: a7b6c36c84fb7336384bfffb6cfb3c8a4b5e6946 xf86-video-intel-2.21.9.tar.gz SHA256: 35690e66ed5a99864b66e7abd86ca4bb2b077949c5e0716a8bc03cbd12623a6a xf86-video-intel-2.21.9.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
Re: libbacklight support for randr backlight property
On Don, 2013-06-06 at 11:08 +1000, Dave Airlie wrote: xbacklight and gnome would really like to use xrandr to control the backlight if possible, I've just taken the property code from intel driver, and hooked it up to libbacklight from git://git.freedesktop.org/git/libbacklight. The kernel can't deal with this due to the insanity that is ACPI and non-ACPI backlight controls, so lets just hope this works instead! The changes look good to me. I've only tested this on my T60p ancient piece of crap, appreciate any testing anyone can give it. It doesn't actually create the properties on this PowerBook, but I'm sure that can be worked out later on. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 65426] openGL glDeleteBuffers does not delete buffers created using glGenBuffers
https://bugs.freedesktop.org/show_bug.cgi?id=65426 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Attachment #80356|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 65426] openGL glDeleteBuffers does not delete buffers created using glGenBuffers
https://bugs.freedesktop.org/show_bug.cgi?id=65426 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Assignee|xorg-driver-ati@lists.x.org |mesa-dev@lists.freedesktop. ||org QA Contact|xorg-t...@lists.x.org | Product|xorg|Mesa Component|Driver/Radeon |Mesa core -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
