Reminder: 2016 X.Org Board of Directors Elections Nomination period is NOW

2016-03-12 Thread Peter Hutterer

We are seeking nominations for candidates for election to the X.Org
Foundation Board of Directors.  All X.Org Foundation members are
eligible for election to the board.

Nominations for the 2016 election are now open and will remain open
until 23:59 UTC on 15 March 2016.

The Board consists of directors elected from the membership.  Each
year, an election is held to bring the total number of directors to
eight. The four members receiving the highest vote totals will serve
as directors for two year terms.

The directors who received two year terms starting in 2015 were
Peter Hutterer, Martin Peres, Rob Clark and Daniel Vetter, They
will continue to serve until their term ends in 2017.  Current
directors whose term expires in 2016 are Alex Deucher, Matt Dew,
Egbert Eich and Keith Packard.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by
the Board of Directors.

A member may nominate themselves or any other member they feel is
qualified. Nominations should be sent to the Election Committee at
electi...@x.org.

Nominees shall be required to be current members of the X.Org
Foundation, and submit a  personal statement of up to 200 words that
will be provided to prospective voters.  The collected statements,
along with the statement of contribution to the X.Org Foundation in
the members account page on http://members.x.org, will be made
available to all voters to help them make their voting decisions.

Nominations, membership applications or renewals and completed
personal statements must be received no later than 23:59 UTC on 15 March
2016.

The slate of candidates will be published 17 March
2016 and candidate Q will begin then.  The deadline for Xorg
membership applications and renewals is 17 March 2016.

Cheers,
  Peter, on behalf of the X.Org BoD

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: allow switching from software to hardware cursors.

2016-03-12 Thread Michael Thayer

Hello Jasper,

My case is virtual machine cursor pass-through.  VirtualBox has a 
setting which lets the user enable or disable guest-host cursor 
integration.  When it is enabled, the guest pointer position tracks the 
host one, and the guest cursor is rendered by the host.  When it is 
disabled, the guest and host pointer positions are independent, and in 
this case the guest renders its cursor itself in software.  The user can 
switch between the two at any time, though of course in practice 
switches do not occur in close succession.  But if integration was 
previously enabled, then the user disables it and the guest re-loads the 
previous cursor, it will be told that hardware rendering is not 
possible, which it was previously (and vice-versa).


Sorry that was so long - hope it was clear enough.

Regards,

Michael

On 12.03.2016 20:19, Jasper St. Pierre wrote:

Can you give an example of when drmSetCursor2 would fail sometimes but
not always, enough to switch back and forth actively?

I'm not a huge fan of the patch because now errors could cause really
bizarre double-cursor, or no-cursor flickering, since there is no
guarantee that the swapover happens in the same frame.

We sort-of tried this in Weston for something else (we rendered
certain windows in overlays) and had to turn it off and go to always
SW because of the obnoxious flickering, at least until atomic landed.

On Sat, Mar 12, 2016 at 3:54 AM, Michael Thayer
 wrote:

Hello,

I would just like to politely draw attention to this again.  I would assume
from the silence that the people who might review it don't think it is a
completely wrong thing (that would not take long to say) but don't have the
spare cycles to take a closer look.  Any idea when someone might have twenty
minutes to review it?

Regards,

Michael


On 06.03.2016 12:56, Michael Thayer wrote:


Currently if modesetting ever fails to set a hardware cursor it will
switch
to using a software cursor and never go back.  Change this to try a
hardware
cursor first every time a new one is set.  This is needed because hardware
may be able to handle some cursors in harware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not
others.

Signed-off-by: Michael Thayer 
---
Made the commit message more verbose on Emil's request.

   hw/xfree86/drivers/modesetting/drmmode_display.c | 47
++--
   1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 0d34ca1..36c3093 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -485,44 +485,36 @@ drmmode_set_cursor_position(xf86CrtcPtr crtc, int x,
int y)
   drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, x,
y);
   }

-static void
+static Bool
   drmmode_set_cursor(xf86CrtcPtr crtc)
   {
   drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
   drmmode_ptr drmmode = drmmode_crtc->drmmode;
   uint32_t handle = drmmode_crtc->cursor_bo->handle;
   modesettingPtr ms = modesettingPTR(crtc->scrn);
-static Bool use_set_cursor2 = TRUE;
   int ret;

-if (use_set_cursor2) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-CursorPtr cursor = xf86_config->cursor;
-
-ret =
-drmModeSetCursor2(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id,
-  handle, ms->cursor_width,
ms->cursor_height,
-  cursor->bits->xhot, cursor->bits->yhot);
-if (!ret)
-return;
-if (ret == -EINVAL)
-use_set_cursor2 = FALSE;
-}
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
+CursorPtr cursor = xf86_config->cursor;

-ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
handle,
-   ms->cursor_width, ms->cursor_height);
+ret =
+drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+  handle, ms->cursor_width, ms->cursor_height,
+  cursor->bits->xhot, cursor->bits->yhot);
+if (!ret)
+return TRUE;

-if (ret) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
+/* -EINVAL can mean bad cursor parameters or Cursor2 API not
supported. */
+if (ret == -EINVAL)
+ret = drmModeSetCursor(drmmode->fd,
drmmode_crtc->mode_crtc->crtc_id,
+   handle, ms->cursor_width,
ms->cursor_height);

-cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
-drmmode_crtc->drmmode->sw_cursor = TRUE;
-/* fallback to swcursor */
-}
+if (ret)
+return FALSE; /* fallback to swcursor */
+return TRUE;
 

Re: [PATCH:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

2016-03-12 Thread Jasper St. Pierre
"Safe multi-line macros" have been suggested before, and turned down.
The C extension that gcc supports is statement expressions:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

On Sat, Mar 12, 2016 at 11:15 AM, walter harms  wrote:
>
>
> Am 12.03.2016 19:43, schrieb Matt Turner:
>> On Sat, Mar 12, 2016 at 10:24 AM, walter harms  wrote:
>>>
>>>
>>> Am 12.03.2016 19:15, schrieb Alan Coopersmith:
 Cleans up several -Wempty-body warnings from gcc 5.3

 Signed-off-by: Alan Coopersmith 
 ---
  def.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/def.h b/def.h
 index 1930cde..59670a9 100644
 --- a/def.h
 +++ b/def.h
 @@ -82,9 +82,9 @@ extern int  _debugmask;
   * 3 show #include SYMBOL
   * 4-6   unused
   */
 -#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
 +#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; 
 } while(0)
  #else
 -#define  debug(level,arg) /**/
 +#define  debug(level,arg) do { /**/ } while (0)
  #endif /* DEBUG */

  typedef  unsigned char boolean;
>>>
>>>
>>>  #definedebug(level,arg)   while(0)
>>>
>>> should be sufficient (not tested)
>>
>> Maybe, but that sure looks strange to my eye, while the do { ... }
>> while(0) pattern is well recognized.
>
> for me other way around :)
>
> never mind, both are a noop, someone could propose this as C extension ,)
>
> re,
>  wh
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: allow switching from software to hardware cursors.

2016-03-12 Thread Jasper St. Pierre
Can you give an example of when drmSetCursor2 would fail sometimes but
not always, enough to switch back and forth actively?

I'm not a huge fan of the patch because now errors could cause really
bizarre double-cursor, or no-cursor flickering, since there is no
guarantee that the swapover happens in the same frame.

We sort-of tried this in Weston for something else (we rendered
certain windows in overlays) and had to turn it off and go to always
SW because of the obnoxious flickering, at least until atomic landed.

On Sat, Mar 12, 2016 at 3:54 AM, Michael Thayer
 wrote:
> Hello,
>
> I would just like to politely draw attention to this again.  I would assume
> from the silence that the people who might review it don't think it is a
> completely wrong thing (that would not take long to say) but don't have the
> spare cycles to take a closer look.  Any idea when someone might have twenty
> minutes to review it?
>
> Regards,
>
> Michael
>
>
> On 06.03.2016 12:56, Michael Thayer wrote:
>>
>> Currently if modesetting ever fails to set a hardware cursor it will
>> switch
>> to using a software cursor and never go back.  Change this to try a
>> hardware
>> cursor first every time a new one is set.  This is needed because hardware
>> may be able to handle some cursors in harware and others not, or virtual
>> hardware may be able to handle hardware cursors at some times and not
>> others.
>>
>> Signed-off-by: Michael Thayer 
>> ---
>> Made the commit message more verbose on Emil's request.
>>
>>   hw/xfree86/drivers/modesetting/drmmode_display.c | 47
>> ++--
>>   1 file changed, 20 insertions(+), 27 deletions(-)
>>
>> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
>> b/hw/xfree86/drivers/modesetting/drmmode_display.c
>> index 0d34ca1..36c3093 100644
>> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
>> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
>> @@ -485,44 +485,36 @@ drmmode_set_cursor_position(xf86CrtcPtr crtc, int x,
>> int y)
>>   drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, x,
>> y);
>>   }
>>
>> -static void
>> +static Bool
>>   drmmode_set_cursor(xf86CrtcPtr crtc)
>>   {
>>   drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
>>   drmmode_ptr drmmode = drmmode_crtc->drmmode;
>>   uint32_t handle = drmmode_crtc->cursor_bo->handle;
>>   modesettingPtr ms = modesettingPTR(crtc->scrn);
>> -static Bool use_set_cursor2 = TRUE;
>>   int ret;
>>
>> -if (use_set_cursor2) {
>> -xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
>> -CursorPtr cursor = xf86_config->cursor;
>> -
>> -ret =
>> -drmModeSetCursor2(drmmode->fd,
>> drmmode_crtc->mode_crtc->crtc_id,
>> -  handle, ms->cursor_width,
>> ms->cursor_height,
>> -  cursor->bits->xhot, cursor->bits->yhot);
>> -if (!ret)
>> -return;
>> -if (ret == -EINVAL)
>> -use_set_cursor2 = FALSE;
>> -}
>> +xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
>> +CursorPtr cursor = xf86_config->cursor;
>>
>> -ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
>> handle,
>> -   ms->cursor_width, ms->cursor_height);
>> +ret =
>> +drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
>> +  handle, ms->cursor_width, ms->cursor_height,
>> +  cursor->bits->xhot, cursor->bits->yhot);
>> +if (!ret)
>> +return TRUE;
>>
>> -if (ret) {
>> -xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
>> -xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
>> +/* -EINVAL can mean bad cursor parameters or Cursor2 API not
>> supported. */
>> +if (ret == -EINVAL)
>> +ret = drmModeSetCursor(drmmode->fd,
>> drmmode_crtc->mode_crtc->crtc_id,
>> +   handle, ms->cursor_width,
>> ms->cursor_height);
>>
>> -cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
>> -drmmode_crtc->drmmode->sw_cursor = TRUE;
>> -/* fallback to swcursor */
>> -}
>> +if (ret)
>> +return FALSE; /* fallback to swcursor */
>> +return TRUE;
>>   }
>>
>> -static void
>> +static Bool
>>   drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
>>   {
>>   modesettingPtr ms = modesettingPTR(crtc->scrn);
>> @@ -537,7 +529,8 @@ drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32
>> *image)
>>   ptr[i] = image[i];  // cpu_to_le32(image[i]);
>>
>>   if (drmmode_crtc->cursor_up)
>> -drmmode_set_cursor(crtc);
>> +return drmmode_set_cursor(crtc);
>> +return TRUE;
>>   }
>>
>>   static void
>> @@ -799,7 +792,7 @@ static const xf86CrtcFuncsRec drmmode_crtc_funcs = {
>>   .set_cursor_position = 

Re: [PATCH:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

2016-03-12 Thread walter harms


Am 12.03.2016 19:43, schrieb Matt Turner:
> On Sat, Mar 12, 2016 at 10:24 AM, walter harms  wrote:
>>
>>
>> Am 12.03.2016 19:15, schrieb Alan Coopersmith:
>>> Cleans up several -Wempty-body warnings from gcc 5.3
>>>
>>> Signed-off-by: Alan Coopersmith 
>>> ---
>>>  def.h | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/def.h b/def.h
>>> index 1930cde..59670a9 100644
>>> --- a/def.h
>>> +++ b/def.h
>>> @@ -82,9 +82,9 @@ extern int  _debugmask;
>>>   * 3 show #include SYMBOL
>>>   * 4-6   unused
>>>   */
>>> -#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
>>> +#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; 
>>> } while(0)
>>>  #else
>>> -#define  debug(level,arg) /**/
>>> +#define  debug(level,arg) do { /**/ } while (0)
>>>  #endif /* DEBUG */
>>>
>>>  typedef  unsigned char boolean;
>>
>>
>>  #definedebug(level,arg)   while(0)
>>
>> should be sufficient (not tested)
> 
> Maybe, but that sure looks strange to my eye, while the do { ... }
> while(0) pattern is well recognized.

for me other way around :)

never mind, both are a noop, someone could propose this as C extension ,)

re,
 wh
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:xf86-video-s3] When checking malloc for success, it helps to use == NULL, instead of =

2016-03-12 Thread Alan Coopersmith
Fixes gcc 5.3 compiler warning:
s3_bios.c: In function 'find_bios_string':
s3_bios.c:49:2: warning: suggest parentheses around assignment used as
truth value [-Wparentheses]
  if (bios = NULL)
^

[Tested by compiling only, as I have no S3 hardware, but clearly no one
 else has tested this code since commit c41a1188ce53 in 2009, as it would
 be segfaulting if run.]

Signed-off-by: Alan Coopersmith 
---
 src/s3_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/s3_bios.c b/src/s3_bios.c
index 323e2ce..1c7c5fe 100644
--- a/src/s3_bios.c
+++ b/src/s3_bios.c
@@ -46,7 +46,7 @@ static unsigned char *find_bios_string(ScrnInfoPtr pScrn, int 
BIOSbase,
S3Ptr pS3 = S3PTR(pScrn);
 
bios = malloc(BIOS_BSIZE);
-   if (bios = NULL)
+   if (bios == NULL)
return NULL;
 
if (!init) {
-- 
2.6.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

2016-03-12 Thread Matt Turner
On Sat, Mar 12, 2016 at 10:24 AM, walter harms  wrote:
>
>
> Am 12.03.2016 19:15, schrieb Alan Coopersmith:
>> Cleans up several -Wempty-body warnings from gcc 5.3
>>
>> Signed-off-by: Alan Coopersmith 
>> ---
>>  def.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/def.h b/def.h
>> index 1930cde..59670a9 100644
>> --- a/def.h
>> +++ b/def.h
>> @@ -82,9 +82,9 @@ extern int  _debugmask;
>>   * 3 show #include SYMBOL
>>   * 4-6   unused
>>   */
>> -#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
>> +#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; } 
>> while(0)
>>  #else
>> -#define  debug(level,arg) /**/
>> +#define  debug(level,arg) do { /**/ } while (0)
>>  #endif /* DEBUG */
>>
>>  typedef  unsigned char boolean;
>
>
>  #definedebug(level,arg)   while(0)
>
> should be sufficient (not tested)

Maybe, but that sure looks strange to my eye, while the do { ... }
while(0) pattern is well recognized.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

2016-03-12 Thread walter harms


Am 12.03.2016 19:15, schrieb Alan Coopersmith:
> Cleans up several -Wempty-body warnings from gcc 5.3
> 
> Signed-off-by: Alan Coopersmith 
> ---
>  def.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/def.h b/def.h
> index 1930cde..59670a9 100644
> --- a/def.h
> +++ b/def.h
> @@ -82,9 +82,9 @@ extern int  _debugmask;
>   * 3 show #include SYMBOL
>   * 4-6   unused
>   */
> -#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
> +#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; } 
> while(0)
>  #else
> -#define  debug(level,arg) /**/
> +#define  debug(level,arg) do { /**/ } while (0)
>  #endif /* DEBUG */
>  
>  typedef  unsigned char boolean;


 #definedebug(level,arg)   while(0)

should be sufficient (not tested)

re,
 wh
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

2016-03-12 Thread Alan Coopersmith
Cleans up several -Wempty-body warnings from gcc 5.3

Signed-off-by: Alan Coopersmith 
---
 def.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/def.h b/def.h
index 1930cde..59670a9 100644
--- a/def.h
+++ b/def.h
@@ -82,9 +82,9 @@ extern int_debugmask;
  * 3   show #include SYMBOL
  * 4-6 unused
  */
-#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
+#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; } 
while(0)
 #else
-#definedebug(level,arg) /**/
+#definedebug(level,arg) do { /**/ } while (0)
 #endif /* DEBUG */
 
 typedefunsigned char boolean;
-- 
2.6.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] modesetting: allow switching from software to hardware cursors.

2016-03-12 Thread Michael Thayer

Hello,

I would just like to politely draw attention to this again.  I would 
assume from the silence that the people who might review it don't think 
it is a completely wrong thing (that would not take long to say) but 
don't have the spare cycles to take a closer look.  Any idea when 
someone might have twenty minutes to review it?


Regards,

Michael

On 06.03.2016 12:56, Michael Thayer wrote:

Currently if modesetting ever fails to set a hardware cursor it will switch
to using a software cursor and never go back.  Change this to try a hardware
cursor first every time a new one is set.  This is needed because hardware
may be able to handle some cursors in harware and others not, or virtual
hardware may be able to handle hardware cursors at some times and not others.

Signed-off-by: Michael Thayer 
---
Made the commit message more verbose on Emil's request.

  hw/xfree86/drivers/modesetting/drmmode_display.c | 47 ++--
  1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 0d34ca1..36c3093 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -485,44 +485,36 @@ drmmode_set_cursor_position(xf86CrtcPtr crtc, int x, int 
y)
  drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, x, y);
  }

-static void
+static Bool
  drmmode_set_cursor(xf86CrtcPtr crtc)
  {
  drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
  drmmode_ptr drmmode = drmmode_crtc->drmmode;
  uint32_t handle = drmmode_crtc->cursor_bo->handle;
  modesettingPtr ms = modesettingPTR(crtc->scrn);
-static Bool use_set_cursor2 = TRUE;
  int ret;

-if (use_set_cursor2) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-CursorPtr cursor = xf86_config->cursor;
-
-ret =
-drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
-  handle, ms->cursor_width, ms->cursor_height,
-  cursor->bits->xhot, cursor->bits->yhot);
-if (!ret)
-return;
-if (ret == -EINVAL)
-use_set_cursor2 = FALSE;
-}
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
+CursorPtr cursor = xf86_config->cursor;

-ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 
handle,
-   ms->cursor_width, ms->cursor_height);
+ret =
+drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+  handle, ms->cursor_width, ms->cursor_height,
+  cursor->bits->xhot, cursor->bits->yhot);
+if (!ret)
+return TRUE;

-if (ret) {
-xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
-xf86CursorInfoPtr cursor_info = xf86_config->cursor_info;
+/* -EINVAL can mean bad cursor parameters or Cursor2 API not supported. */
+if (ret == -EINVAL)
+ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
+   handle, ms->cursor_width, ms->cursor_height);

-cursor_info->MaxWidth = cursor_info->MaxHeight = 0;
-drmmode_crtc->drmmode->sw_cursor = TRUE;
-/* fallback to swcursor */
-}
+if (ret)
+return FALSE; /* fallback to swcursor */
+return TRUE;
  }

-static void
+static Bool
  drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
  {
  modesettingPtr ms = modesettingPTR(crtc->scrn);
@@ -537,7 +529,8 @@ drmmode_load_cursor_argb(xf86CrtcPtr crtc, CARD32 *image)
  ptr[i] = image[i];  // cpu_to_le32(image[i]);

  if (drmmode_crtc->cursor_up)
-drmmode_set_cursor(crtc);
+return drmmode_set_cursor(crtc);
+return TRUE;
  }

  static void
@@ -799,7 +792,7 @@ static const xf86CrtcFuncsRec drmmode_crtc_funcs = {
  .set_cursor_position = drmmode_set_cursor_position,
  .show_cursor = drmmode_show_cursor,
  .hide_cursor = drmmode_hide_cursor,
-.load_cursor_argb = drmmode_load_cursor_argb,
+.load_cursor_argb_check = drmmode_load_cursor_argb,

  .gamma_set = drmmode_crtc_gamma_set,
  .destroy = NULL,/* XXX */



--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: