Reminder: 2016 X.Org Board of Directors Elections Nomination period is NOW
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.
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 Thayerwrote: 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
"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 harmswrote: > > > 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.
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 Thayerwrote: > 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
Am 12.03.2016 19:43, schrieb Matt Turner: > On Sat, Mar 12, 2016 at 10:24 AM, walter harmswrote: >> >> >> 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 =
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
On Sat, Mar 12, 2016 at 10:24 AM, walter harmswrote: > > > 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
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
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.
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: