Peter Hutterer peter.hutte...@who-t.net writes:
please add some info about your system configuration next time. I usually
run make check before requesting a pull, so if this crashes it means that
there's some difference to my box. in this case 32 bit userspace, segfault
caused by pointer size
On Fri, Jun 29, 2012 at 3:48 AM, Keith Packard kei...@keithp.com wrote:
Aaron Plattner aplatt...@nvidia.com writes:
On 06/28/2012 03:21 AM, Dave Airlie wrote:
Keith, thoughts?
Well, RRScreenChangeNotify is supposed to signal any 'screen
configuration changes', which presumably includes
+#define RR_Provider_Flag_Dynamic 1
+#define RR_Provider_Flag_MultiMaster 2
Are these documented anywhere?
Oops totally forgot to add them, have done in v6.
Dynamic basically means you can make changes to the providers,
MultiMaster is to say xinerama style multiple rendering masters is
From: Dave Airlie airl...@redhat.com
A provider object represents a GPU or virtual device that provides
rendering or output services to the X server.
This is the first rev of a protocol to enumerate providers
devices, set their roles, and provide generic properties based
on output properties for
From: Dave Airlie airl...@redhat.com
A provider object represents a GPU or virtual device that provides
rendering or output services to the X server.
This is the first rev of a protocol to enumerate providers
devices, set their roles, and provide generic properties based
on output properties for
On Fri, Jun 29, 2012 at 12:30 PM, Michel Dänzer mic...@daenzer.net wrote:
[ Did you intentionally not Cc the xorg-devel list? ]
No that was an accident... not sure why I have reply all as default...
On Fre, 2012-06-29 at 12:20 -0400, Kristian Høgsberg wrote:
On Thu, Jun 28, 2012 at 7:39 AM,
On Fre, 2012-06-29 at 12:58 -0400, Kristian Høgsberg wrote:
On Fri, Jun 29, 2012 at 12:30 PM, Michel Dänzer mic...@daenzer.net wrote:
On Fre, 2012-06-29 at 12:20 -0400, Kristian Høgsberg wrote:
On Thu, Jun 28, 2012 at 7:39 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer
ProcRRGetScreenSizeRange uses REQUEST(xRRGetScreenSizeRangeReq) followed by
REQUEST_SIZE_MATCH(xRRGetScreenSizeRangeReq). This happens to work out because
both requests have the same size, so this is not a functional change, just a
cosmetic one.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
On 06/29/12 12:22 PM, Aaron Plattner wrote:
ProcRRGetScreenSizeRange uses REQUEST(xRRGetScreenSizeRangeReq) followed by
REQUEST_SIZE_MATCH(xRRGetScreenSizeRangeReq). This happens to work out
because
both requests have the same size, so this is not a functional change, just a
cosmetic one.
On 06/29/2012 12:57 PM, Alan Coopersmith wrote:
On 06/29/12 12:22 PM, Aaron Plattner wrote:
ProcRRGetScreenSizeRange uses REQUEST(xRRGetScreenSizeRangeReq) followed by
REQUEST_SIZE_MATCH(xRRGetScreenSizeRangeReq). This happens to work out because
d'oh, this should read
ProcRRGetScreenSizeRange uses REQUEST(xRRGetScreenSizeRangeReq) followed by
REQUEST_SIZE_MATCH(xRRGetScreenInfoReq). This happens to work out because both
requests have the same size, so this is not a functional change, just a cosmetic
one.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
From: Ian Romanick ian.d.roman...@intel.com
The server does not want GL extension prototypes. It never links with
anything that could possibly provide implementations of these functions. It
*is* the provide, and it does not provde these symbols. All this does is
create hundreds of warnings
Adds include of sis_dac.h to init.c to force compilers to compare the
definitions, making it obvious that sis_dac.h defined an extra argument
to SiSSetLVDSetc that the function itself didn't have, and that SiSRegInit
expected an unsigned long (in the form of SISIOADDRESS), not the unsigned
short
13 matches
Mail list logo
