Re: xserver: Branch 'master' - 5 commits
On Mon, 2009-02-02 at 11:20 +0100, Michel Dänzer wrote: > On Sun, 2009-02-01 at 09:26 -0800, Eric Anholt wrote: > > > > commit 29b3b88dc744f4919c6709747ddb7baac47486c5 > > Author: Pierre Willenbrock > > Date: Fri Jan 30 21:16:48 2009 -0800 > > > > Prevent double unref of glxdrawables > > > > Found by valgrind. Bug #18917. > > > > diff --git a/glx/glxcmds.c b/glx/glxcmds.c > > index af52672..33954ee 100644 > > --- a/glx/glxcmds.c > > +++ b/glx/glxcmds.c > > @@ -146,6 +146,8 @@ __glXContextDestroy(__GLXcontext *context) > > __glXUnrefDrawable(context->drawPriv); > > if (context->readPriv) > > __glXUnrefDrawable(context->readPriv); > > + context->drawPriv = NULL; > > + context->readPriv = NULL; > > } > > __glXFlushContextCache(); > > } > > @@ -621,6 +623,8 @@ DoMakeCurrent(__GLXclientState *cl, > > __glXUnrefDrawable(prevglxc->drawPriv); > > if (prevglxc->readPriv) > > __glXUnrefDrawable(prevglxc->readPriv); > > + prevglxc->drawPriv = NULL; > > + prevglxc->readPriv = NULL; > > } > > } > > > > diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c > > index 30308ad..40352b4 100644 > > --- a/hw/xfree86/modes/xf86Crtc.c > > +++ b/hw/xfree86/modes/xf86Crtc.c > > @@ -3159,9 +3159,6 @@ xf86_crtc_supports_gamma(ScrnInfoPtr pScrn) > > xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn); > > xf86CrtcPtr crtc; > > > > - if (!xf86_config) > > - return FALSE; > > - > > if (xf86_config->num_crtc == 0) > > return FALSE; > > crtc = xf86_config->crtc[0]; > > The last hunk looks unrelated. This was noted on IRC as well. It should have been amended into the crtc_supports_gamma vs DRI1 fix, but wasn't. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 5 commits
On Sun, 2009-02-01 at 09:26 -0800, Eric Anholt wrote: > > commit 29b3b88dc744f4919c6709747ddb7baac47486c5 > Author: Pierre Willenbrock > Date: Fri Jan 30 21:16:48 2009 -0800 > > Prevent double unref of glxdrawables > > Found by valgrind. Bug #18917. > > diff --git a/glx/glxcmds.c b/glx/glxcmds.c > index af52672..33954ee 100644 > --- a/glx/glxcmds.c > +++ b/glx/glxcmds.c > @@ -146,6 +146,8 @@ __glXContextDestroy(__GLXcontext *context) > __glXUnrefDrawable(context->drawPriv); > if (context->readPriv) > __glXUnrefDrawable(context->readPriv); > + context->drawPriv = NULL; > + context->readPriv = NULL; > } > __glXFlushContextCache(); > } > @@ -621,6 +623,8 @@ DoMakeCurrent(__GLXclientState *cl, > __glXUnrefDrawable(prevglxc->drawPriv); > if (prevglxc->readPriv) > __glXUnrefDrawable(prevglxc->readPriv); > + prevglxc->drawPriv = NULL; > + prevglxc->readPriv = NULL; > } > } > > diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c > index 30308ad..40352b4 100644 > --- a/hw/xfree86/modes/xf86Crtc.c > +++ b/hw/xfree86/modes/xf86Crtc.c > @@ -3159,9 +3159,6 @@ xf86_crtc_supports_gamma(ScrnInfoPtr pScrn) > xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn); > xf86CrtcPtr crtc; > > - if (!xf86_config) > - return FALSE; > - > if (xf86_config->num_crtc == 0) > return FALSE; > crtc = xf86_config->crtc[0]; The last hunk looks unrelated. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Peter Hutterer wrote: Nothing agains't disabling it. But it should be building since commit 6ef46c40e62def4841a4cff4e0b443516a2ed782, and have "the same problems" as kdrive based servers. Since this is probably a case of "nobody cares" to maintain, then it should be better to just remove it. As it is really only useful for being a "simpler" version of Xephyr, and only barely useful for things like "debug grabs" on toolkit codes... > configure.ac |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > New commits: > commit 82fc102568b3d6b0daeb6c5f5b3a1310a7f14fcd > Author: Peter Hutterer > Date: Wed Jan 28 07:51:32 2009 +1000 > > Disable Xnest by default. > > Xneest doesn't build right now and is in the process of being removed. > So > let's not build it by default. > > diff --git a/configure.ac b/configure.ac > index 38397fc..71d37df 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -581,7 +581,7 @@ dnl DDXes. > AC_ARG_ENABLE(xorg,AS_HELP_STRING([--enable-xorg], [Build > Xorg > server (default: auto)]), [XORG=$enableval], [XORG=auto]) > AC_ARG_ENABLE(dmx, AS_HELP_STRING([--enable-dmx], [Build DMX > server (default: no)]), [DMX=$enableval], [DMX=no]) > AC_ARG_ENABLE(xvfb,AS_HELP_STRING([--enable-xvfb], [Build > Xvfb > server (default: yes)]), [XVFB=$enableval], [XVFB=yes]) > -AC_ARG_ENABLE(xnest, AS_HELP_STRING([--enable-xnest], [Build > Xnest server (default: auto)]), [XNEST=$enableval], [XNEST=auto]) > +AC_ARG_ENABLE(xnest, AS_HELP_STRING([--enable-xnest], [Build > Xnest server (default: no)]), [XNEST=$enableval], [XNEST=no]) > AC_ARG_ENABLE(xquartz,AS_HELP_STRING([--enable-xquartz], [Build > Xquartz server for OS-X (default: auto)]), [XQUARTZ=$enableval], > [XQUARTZ=auto]) > AC_ARG_ENABLE(standalone-xpbproxy, > AS_HELP_STRING([--enable-standalone-xpbproxy], [Build a standalone > xpbproxy (in addigion to the one integrated into Xquartz as a separate > thread) (default: no)]), [STANDALONE_XPBPROXY=$enableval], > [STANDALONE_XPBPROXY=no]) > AC_ARG_ENABLE(xwin,AS_HELP_STRING([--enable-xwin], [Build > XWin > server (default: auto)]), [XWIN=$enableval], [XWIN=auto]) Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Colin Guthrie wrote: > 'Twas brillig, and Paulo César Pereira de Andrade at 07/01/09 16:55 did > gyre and gimble: > >> Daniel Stone wrote: >> >>> On Mon, Jan 05, 2009 at 11:25:11AM -0800, Paulo Cesar Pereira de Andrade >>> wrote: >>> -extern CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; +extern _X_EXPORT CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; >>> ?!? >>> >> The XaceHook() function must be exported, or at least extmod >> will fail due to it being an unresolved symbol. >> > > I wont pretend to know anything about this (you know me well enough on > that from Paulo :)) but the about diff applies _X_EXPORT to an array of > CallbackListPtrs, not the XsceHook() function itself. If this is > intended and I'm just not following just ignore me... ignorance is bliss :p > > Col > > XaceHooks is exported so that modules can register / unregister callbacks. Is the export of this variable a problem? API could be added to wrap the registration and unregistration which would allow XaceHooks to be a static variable. It would be 2 new exported functions though, versus the one variable. -- Eamon Walsh National Security Agency ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
'Twas brillig, and Paulo César Pereira de Andrade at 07/01/09 16:55 did gyre and gimble: > Daniel Stone wrote: >> On Mon, Jan 05, 2009 at 11:25:11AM -0800, Paulo Cesar Pereira de Andrade >> wrote: >>> -extern CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; >>> +extern _X_EXPORT CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; >> ?!? > > The XaceHook() function must be exported, or at least extmod > will fail due to it being an unresolved symbol. I wont pretend to know anything about this (you know me well enough on that from Paulo :)) but the about diff applies _X_EXPORT to an array of CallbackListPtrs, not the XsceHook() function itself. If this is intended and I'm just not following just ignore me... ignorance is bliss :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Daniel Stone wrote: > On Mon, Jan 05, 2009 at 11:25:11AM -0800, Paulo Cesar Pereira de Andrade > wrote: >> -extern CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; >> +extern _X_EXPORT CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; > > ?!? If the symbols are in a installed sdk header, they presumably must be exported. I feel that vector could be static in xace.c, but if it must be used by other shared objects, it would still be required at least a function returning a pointer to a callback. In the commit I also wrote about using a format like: extern /* NOEXPORT */ type name ...; to let people know it is in the public sdk header, but not meant to be used by other shared objects, and what would be the proper solution, that is to have a private header for these cases. The XaceHook() function must be exported, or at least extmod will fail due to it being an unresolved symbol. Also note that if you configure with --disable-visibility, or the compiler doesn't support it, that symbol would be available anyway. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Mon, Jan 05, 2009 at 11:25:11AM -0800, Paulo Cesar Pereira de Andrade wrote: > -extern CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; > +extern _X_EXPORT CallbackListPtr XaceHooks[XACE_NUM_HOOKS]; ?!? signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 3 commits
Hi, On Mon, Jan 05, 2009 at 07:44:16AM -0800, Daniel Stone wrote: > commit e351d10773742d1570e976b7c8b6adda5ae6 > Author: Daniel Stone > Date: Mon Jan 5 17:41:38 2009 +0200 > > RandR: Only export Xinerama symbols when building Xinerama support > > Otherwise compilation fails due to sdksyms. This one is fine. > commit 3387cbb7c13636eb62b22640d28df7011c2268f0 > Author: Daniel Stone > Date: Mon Jan 5 11:25:57 2009 +0200 > > XFree86: Xv: Add ClipNotify helper > > Add a ClipNotify helper that lets the driver know about changes in the > clipping of an Xv backing drawable. > > [...] > > commit 55c4ec0a1ef78481b4d82153c19c20fbf88f1624 > Author: Daniel Stone > Date: Mon Jan 5 11:24:24 2009 +0200 > > XFree86: fbdevhw: Add helper function to get fd > > Most devices need to do custom weird ioctls, so let them know what the > fd is. Those two should be fine, but I didn't mean to push them: was waiting for review first. If anyone thinks they're unsuitable enough to be reverted, please feel free. Sorry: my fault for not using git log first. Unspeakable novistry. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, Jan 01, 2009 at 02:26:33PM -0200, Paulo C?sar Pereira de Andrade wrote: > Thanks for the information. I was afraid it could not work > correctly with Solaris or BSD make, given the large amount of > problems to write a small awk script that works everywhere... > But the feature, as noted in "info make" is from SGI make (and > perhaps others), and the other alternative is from SunOS 4. Please use the correct approach of including the static dependencies by default and add a maintainer rule for regeneration them. Using conditional includes for this is entire pointless. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, 2009-01-01 at 14:26 -0200, Paulo César Pereira de Andrade wrote: > Matthieu Herrb wrote: > > Paulo Cesar Pereira de Andrade wrote: > >> hw/xfree86/loader/Makefile.am |6 -- > >> hw/xfree86/loader/sdksyms.sh | 13 + > >> 2 files changed, 17 insertions(+), 2 deletions(-) > >> > >> New commits: > >> commit 86dc660588a615baefb1799d78a501c95a931d77 > >> Author: Paulo Cesar Pereira de Andrade > >> Date: Tue Dec 23 18:07:54 2008 -0200 > >> > >> Improve sdksyms.c automatic generation (Fix #19245). > >> > >> Since it is already parsing cpp output, create a dependency file > >> in the same process. This will cause sdksyms.c to be regenerated > >> whenever a sdk header is modified. > >> This also uses the gmake 'sinclude' directive (don't fail if > >> included file doesn't exist). This should not cause any problems > >> given that gmake only constructs are used in several other > >> Makefiles. > >> > > > > Sorry no, so far I was able to use bmake (BSD make) for all X.Org > > modules. What other Makefiles are using GNU make constructs? > > Thanks for the information. I was afraid it could not work > correctly with Solaris or BSD make, given the large amount of > problems to write a small awk script that works everywhere... > But the feature, as noted in "info make" is from SGI make (and > perhaps others), and the other alternative is from SunOS 4. FWIW, FreeBSD make at least has support for sinclude. .sinclude "file" Like .include, but silently ignored if the file cannot be found and opened. robert. > Paulo > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Matthieu Herrb wrote: > Paulo Cesar Pereira de Andrade wrote: >> hw/xfree86/loader/Makefile.am |6 -- >> hw/xfree86/loader/sdksyms.sh | 13 + >> 2 files changed, 17 insertions(+), 2 deletions(-) >> >> New commits: >> commit 86dc660588a615baefb1799d78a501c95a931d77 >> Author: Paulo Cesar Pereira de Andrade >> Date: Tue Dec 23 18:07:54 2008 -0200 >> >> Improve sdksyms.c automatic generation (Fix #19245). >> >> Since it is already parsing cpp output, create a dependency file >> in the same process. This will cause sdksyms.c to be regenerated >> whenever a sdk header is modified. >> This also uses the gmake 'sinclude' directive (don't fail if >> included file doesn't exist). This should not cause any problems >> given that gmake only constructs are used in several other >> Makefiles. >> > > Sorry no, so far I was able to use bmake (BSD make) for all X.Org > modules. What other Makefiles are using GNU make constructs? Thanks for the information. I was afraid it could not work correctly with Solaris or BSD make, given the large amount of problems to write a small awk script that works everywhere... But the feature, as noted in "info make" is from SGI make (and perhaps others), and the other alternative is from SunOS 4. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Paulo Cesar Pereira de Andrade wrote: > hw/xfree86/loader/Makefile.am |6 -- > hw/xfree86/loader/sdksyms.sh | 13 + > 2 files changed, 17 insertions(+), 2 deletions(-) > > New commits: > commit 86dc660588a615baefb1799d78a501c95a931d77 > Author: Paulo Cesar Pereira de Andrade > Date: Tue Dec 23 18:07:54 2008 -0200 > > Improve sdksyms.c automatic generation (Fix #19245). > > Since it is already parsing cpp output, create a dependency file > in the same process. This will cause sdksyms.c to be regenerated > whenever a sdk header is modified. > This also uses the gmake 'sinclude' directive (don't fail if > included file doesn't exist). This should not cause any problems > given that gmake only constructs are used in several other Makefiles. > Sorry no, so far I was able to use bmake (BSD make) for all X.Org modules. What other Makefiles are using GNU make constructs? -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Tue, Dec 30, 2008 at 01:56:22PM +0100, Sascha Hlusiak wrote: > Daniel Stone schrieb: > > commit 48dbaf173a82693fd72953983da9fc556cd1c6ed > > Author: Daniel Stone > > Date: Tue Dec 30 12:17:14 2008 +1100 > > > > XKB: Also copy keyboard feedback when copying the keymap > > > > When updating the XKB keymap, make sure the keyboard feedback is also > > copied, to preserve autorepeat settings etc. > > > > Signed-off-by: Daniel Stone > > Wasn't that commit meant for server-1.6-branch? Master worked fine > before, and it was different anyway because of MPX, wasn't it? Yeesh. Keith, do you want to cherry-pick this to 1.6? Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
'Twas brillig, and Sascha Hlusiak at 30/12/08 12:56 did gyre and gimble: > Daniel Stone schrieb: >> xkb/xkbUtils.c | 17 - >> 1 file changed, 16 insertions(+), 1 deletion(-) >> >> New commits: >> commit 48dbaf173a82693fd72953983da9fc556cd1c6ed >> Author: Daniel Stone >> Date: Tue Dec 30 12:17:14 2008 +1100 >> >> XKB: Also copy keyboard feedback when copying the keymap >> >> When updating the XKB keymap, make sure the keyboard feedback is also >> copied, to preserve autorepeat settings etc. >> >> Signed-off-by: Daniel Stone > > Wasn't that commit meant for server-1.6-branch? Master worked fine > before, and it was different anyway because of MPX, wasn't it? The details are on: http://bugs.freedesktop.org/show_bug.cgi?id=19048 Not sure if that helps tho' :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Daniel Stone schrieb: > xkb/xkbUtils.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > > New commits: > commit 48dbaf173a82693fd72953983da9fc556cd1c6ed > Author: Daniel Stone > Date: Tue Dec 30 12:17:14 2008 +1100 > > XKB: Also copy keyboard feedback when copying the keymap > > When updating the XKB keymap, make sure the keyboard feedback is also > copied, to preserve autorepeat settings etc. > > Signed-off-by: Daniel Stone Wasn't that commit meant for server-1.6-branch? Master worked fine before, and it was different anyway because of MPX, wasn't it? - Sascha signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Fri, 2008-12-19 at 14:37 -0800, Maarten Maathuis wrote:
>
> commit 2db7b66863ae6055c3ce13c88b36d620de8a4d75
> Author: Maarten Maathuis
> Date: Fri Dec 19 23:12:37 2008 +0100
>
> exa: a few cleanups
>
> - Some warnings silenced.
> - Some whitespace cleanup.
>
> diff --git a/exa/exa.c b/exa/exa.c
> index 6dfde4c..7b732eb 100644
> --- a/exa/exa.c
> +++ b/exa/exa.c
> @@ -72,7 +72,7 @@ exaGetPixmapOffset(PixmapPtr pPix)
> {
> ExaScreenPriv (pPix->drawable.pScreen);
>
> -return ((unsigned long)ExaGetPixmapAddress(pPix) -
> +return ((unsigned long)(unsigned long *)ExaGetPixmapAddress(pPix) -
> (unsigned long)pExaScr->info->memoryBase);
This looks wrong... what's the problem you're trying to solve here?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86SetGamma crashes the server [Re: xserver: Branch 'master']
I should swap the reply button for reply to all :-)
On 12/17/2008 10:50 PM, Maarten Maathuis wrote:
> On 12/17/2008 09:33 PM, Aaron Plattner wrote:
>> On Wed, Dec 17, 2008 at 08:05:24AM -0800, Maarten Maathuis wrote:
>>> hw/xfree86/common/Makefile.am |2
>>> hw/xfree86/common/xf86Helper.c |6 +
>>> hw/xfree86/common/xf86cmap.c |5 +
>>> hw/xfree86/modes/xf86Crtc.c| 128
>>> -
>>> hw/xfree86/modes/xf86Crtc.h| 16 +
>>> hw/xfree86/modes/xf86RandR12.c | 52
>>> randr/randrstr.h | 12 +++
>>> randr/rrcrtc.c | 35 ++-
>>> 8 files changed, 249 insertions(+), 7 deletions(-)
>>>
>>> New commits:
>>> commit 91f73b79b7ae64e5b846d1efeb470bb61a913720
>>> Author: Maarten Maathuis
>>> Date: Wed Dec 17 16:56:26 2008 +0100
>>>
>>> randr: Improve per-crtc gamma support.
>>>
>>> - The Gamma values from the monitor section are now used during
>>> initial config.
>>> - The old colormap system is disabled when gamma set hook is
>>> available.
>>> - Gamma values are now persistent for the lifetime of the xserver.
>>> - This requires no driver changes and should be driver ABI
>>> compatible.
>>
>
> I've got some changes pending, i'll add a check for non-NULL'ness of
> xf86_config as well.
>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7f1c582006f0 (LWP 15464)]
>> 0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0) at
>> /home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
>> 3146for (c = 0; c< xf86_config->num_crtc; c++) {
>> (gdb) bt
>> #0 0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0)
>> at /home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
>> #1 0x0045966b in xf86SetGamma (scrp=0x899ac0, gamma={red =
>> 0, green = 0, blue = 0})
>> at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Helper.c:925
>> #2 0x7f1c54264788 in VESAPreInit (pScrn=0x899ac0, flags=> optimized out>)
>> at /home/aaron/X/modular/driver/xf86-video-vesa/src/vesa.c:640
>> #3 0x00453ab8 in InitOutput (pScreenInfo=0x8702a0, argc=4,
>> argv=0x7fff60336308)
>> at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Init.c:1007
>> #4 0x00428315 in main (argc=4, argv=0x7fff60336308,
>> envp=0x7fff60336330) at /home/aaron/X/modular/xserver/dix/main.c:308
>> (gdb) p xf86_config
>> $1 = (xf86CrtcConfigPtr) 0x21
>> (gdb) p xf86CrtcConfigPrivateIndex
>> $2 = -1
>> ___
>> xorg mailing list
>> xorg@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xf86SetGamma crashes the server [Re: xserver: Branch 'master']
On Wed, Dec 17, 2008 at 08:05:24AM -0800, Maarten Maathuis wrote:
> hw/xfree86/common/Makefile.am |2
> hw/xfree86/common/xf86Helper.c |6 +
> hw/xfree86/common/xf86cmap.c |5 +
> hw/xfree86/modes/xf86Crtc.c| 128
> -
> hw/xfree86/modes/xf86Crtc.h| 16 +
> hw/xfree86/modes/xf86RandR12.c | 52
> randr/randrstr.h | 12 +++
> randr/rrcrtc.c | 35 ++-
> 8 files changed, 249 insertions(+), 7 deletions(-)
>
> New commits:
> commit 91f73b79b7ae64e5b846d1efeb470bb61a913720
> Author: Maarten Maathuis
> Date: Wed Dec 17 16:56:26 2008 +0100
>
> randr: Improve per-crtc gamma support.
>
> - The Gamma values from the monitor section are now used during initial
> config.
> - The old colormap system is disabled when gamma set hook is available.
> - Gamma values are now persistent for the lifetime of the xserver.
> - This requires no driver changes and should be driver ABI compatible.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1c582006f0 (LWP 15464)]
0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0) at
/home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
3146for (c = 0; c < xf86_config->num_crtc; c++) {
(gdb) bt
#0 0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0) at
/home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
#1 0x0045966b in xf86SetGamma (scrp=0x899ac0, gamma={red = 0, green =
0, blue = 0})
at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Helper.c:925
#2 0x7f1c54264788 in VESAPreInit (pScrn=0x899ac0, flags=)
at /home/aaron/X/modular/driver/xf86-video-vesa/src/vesa.c:640
#3 0x00453ab8 in InitOutput (pScreenInfo=0x8702a0, argc=4,
argv=0x7fff60336308)
at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Init.c:1007
#4 0x00428315 in main (argc=4, argv=0x7fff60336308,
envp=0x7fff60336330) at /home/aaron/X/modular/xserver/dix/main.c:308
(gdb) p xf86_config
$1 = (xf86CrtcConfigPtr) 0x21
(gdb) p xf86CrtcConfigPrivateIndex
$2 = -1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Tue, 2008-12-09 at 15:12 -0500, Peter Harris wrote: > David Gerard wrote: > > 2008/12/9 Adam Jackson <[EMAIL PROTECTED]>: > > > >> 1) vm86 mode is an x86ism. It doesn't work in long mode, and almost > >> certainly never will. 64-bit desktops are an increasingly large > >> percentage of the world. It's worth having only one set of bugs, for > >> the same reason we don't ship cfb anymore. > > > > > > Quick off-topic historical question - what is/was cfb? > > The precursor to fb (along with mfb). ... which are, themselves, the code that implements software rendering for core X (and if you're fb, Render too). - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
David Gerard wrote: > 2008/12/9 Adam Jackson <[EMAIL PROTECTED]>: > >> 1) vm86 mode is an x86ism. It doesn't work in long mode, and almost >> certainly never will. 64-bit desktops are an increasingly large >> percentage of the world. It's worth having only one set of bugs, for >> the same reason we don't ship cfb anymore. > > > Quick off-topic historical question - what is/was cfb? The precursor to fb (along with mfb). Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
2008/12/9 Adam Jackson <[EMAIL PROTECTED]>: > 1) vm86 mode is an x86ism. It doesn't work in long mode, and almost > certainly never will. 64-bit desktops are an increasingly large > percentage of the world. It's worth having only one set of bugs, for > the same reason we don't ship cfb anymore. Quick off-topic historical question - what is/was cfb? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Tue, 2008-12-09 at 15:50 +0100, Luc Verhaegen wrote: > On Mon, Dec 08, 2008 at 01:29:10PM -0800, Adam Jackson wrote: > > configure.ac |1 - > > 1 file changed, 1 deletion(-) > > > > New commits: > > commit 58a27d2932164e43c0db42b1286ec2f95250b420 > > Author: Adam Jackson <[EMAIL PROTECTED]> > > Date: Mon Dec 8 16:28:00 2008 -0500 > > > > Default to x86emu even on i386 linux > > > > vm86 mode is a bad idea anyway, and using the emulator everywhere > > means we get a consistent set of bugs. > > What triggered this choice, where was this discussed? There's a fair bit of history here. I've bitched about this furiously in so many other fora (including at least the last two XD[CS] I've attended) that I assumed I'd done so on this list too, but it seems I haven't, so here's the story. 1) vm86 mode is an x86ism. It doesn't work in long mode, and almost certainly never will. 64-bit desktops are an increasingly large percentage of the world. It's worth having only one set of bugs, for the same reason we don't ship cfb anymore. 2) vm86 doesn't work under Xen dom0 kernels. This is, admittedly, a Xen bug, but it's been there for over two years and doesn't seem to be going anywhere. 3) vm86 mode is intrinsically unsafe. For our purposes, it requires the zero page to be mapped. This means that while vm86 syscalls are running, null pointer dereferences in the kernel are not _faults_. The kernel will carry on its merry way instead of crashing. This is a security problem that (in other forms) has been exploited in the wild. Current selinux policy does not allow you to map memory that low without a magic "oh man I hope this is safe" boolean, for exactly this reason. Whereas with x86emu, you're running in a virtualized address space anyway, so faking the low page is the same as faking all the others. 4) vm86 mode is intrinsically unsatisfiable. Many laptop BIOSes will flip to unreal mode so they can access memory in the E820 reserved region, the highest 16M or so of address space. That bit of memory is part of the kernel's half of the world, and is not directly mappable (in the MAP_FIXED sense) in user space. Again, in x86emu, this is not a problem because you have to fake the whole memory map anyway. 5) vm86 mode is not real mode. It's a subset of real mode. Huge swaths of instructions and addressing modes are legal in real mode but not vm86 mode. BIOSes do not run in vm86 mode, they run in real mode, and the instruction set they use reflects this and includes instructions outside of what's strictly legal in vm86 mode. The only way we stand a chance of being resilient in the face of variations across what different CPUs allow in vm86 mode, is by not using it. 6) For all of points 3, 4, and 5 above, you could work around them to a greater or lesser extent by trapping the troublesome things and handling them in the vm86 wrapper, the way we do with I/O cycles already. But doing this is equivalent to knowing how to decode every x86 instruction so you can find the source and destination of each operand in memory, and then doing just enough partial emulation to finish the op. If you think that sounds equivalent to using the emulator in the first place, you just might be on to something there. So in short: vm86 is dangerous, doesn't work right, and isn't used on significant numbers of machines already. As a bit of empirical evidence, Fedora has shipped x86emu everywhere since Fedora 7 (eighteen months old now). Debian unstable changed to do likewise at about the same time, and will almost certainly release in this configuration whenever Lenny happens. Ubuntu has shipped x86emu on all arches since Gutsy (2007.10), courtesy of Debian rebases. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Mon, Dec 08, 2008 at 01:29:10PM -0800, Adam Jackson wrote: > configure.ac |1 - > 1 file changed, 1 deletion(-) > > New commits: > commit 58a27d2932164e43c0db42b1286ec2f95250b420 > Author: Adam Jackson <[EMAIL PROTECTED]> > Date: Mon Dec 8 16:28:00 2008 -0500 > > Default to x86emu even on i386 linux > > vm86 mode is a bad idea anyway, and using the emulator everywhere > means we get a consistent set of bugs. What triggered this choice, where was this discussed? Luc Verhaegen. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 3 commits
Hi, > You appear to have taken my patch and s/fprintf(stderr, /perror(/. > Generally in a situation like this one would leave original authorship > intact (even my comments were preserved!). Don't know why I changed that :-) It opens space for bikeshedding on something that should never happen (cvt failing to allocate memory). Anyway, I did not want to mean disrespectful or plagiarize your work. The patch is trivial, would not apply cleanly due to other changes, and you forgot to update configure.ac. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 3 commits
On Wed, 2008-12-03 at 20:52 -0800, Paulo Cesar Pereira de Andrade wrote:
> .gitignore | 92 ++-
> Makefile.am|2
> configure.ac |1
> hw/xfree86/Makefile.am |4 -
> hw/xfree86/dummylib/Makefile.am| 38 ---
> hw/xfree86/dummylib/README |7 --
> hw/xfree86/dummylib/dixprivates.c | 19 -
> hw/xfree86/dummylib/dummylib.h |9 --
> hw/xfree86/dummylib/fatalerror.c | 25 ---
> hw/xfree86/dummylib/getemptypci.c | 19 -
> hw/xfree86/dummylib/getvalidbios.c | 19 -
> hw/xfree86/dummylib/logvwrite.c| 21 --
> hw/xfree86/dummylib/pcitestmulti.c | 19 -
> hw/xfree86/dummylib/verrorf.c | 19 -
> hw/xfree86/dummylib/xalloc.c | 111
> -
> hw/xfree86/dummylib/xf86addrestolist.c | 24 ---
> hw/xfree86/dummylib/xf86allocscripi.c | 19 -
> hw/xfree86/dummylib/xf86drvmsg.c | 24 ---
> hw/xfree86/dummylib/xf86drvmsgverb.c | 24 ---
> hw/xfree86/dummylib/xf86errorf.c | 33 -
> hw/xfree86/dummylib/xf86errorfverb.c | 24 ---
> hw/xfree86/dummylib/xf86getverb.c | 19 -
> hw/xfree86/dummylib/xf86info.c | 12 ---
> hw/xfree86/dummylib/xf86msg.c | 24 ---
> hw/xfree86/dummylib/xf86msgverb.c | 24 ---
> hw/xfree86/dummylib/xf86opt.c | 25 ---
> hw/xfree86/dummylib/xf86screens.c | 12 ---
> hw/xfree86/dummylib/xf86servisinit.c | 19 -
> hw/xfree86/dummylib/xf86verbose.c | 12 ---
> hw/xfree86/utils/cvt/Makefile.am |2
> hw/xfree86/utils/cvt/cvt.c | 28
> 31 files changed, 40 insertions(+), 690 deletions(-)
> .PHONY: ChangeLog
> commit 5dbe70dd52fd8daf8d0797951cc5a758d2c3b44c
> Author: Paulo Cesar Pereira de Andrade <[EMAIL PROTECTED]>
> Date: Thu Dec 4 01:57:46 2008 -0200
>
> Remove dummylib.
>
> Only cvt required it, and only used XNF{,c}alloc
> via xnf{,c}alloc macros.
> Based on patch by Eric Anholt.
>
You appear to have taken my patch and s/fprintf(stderr, /perror(/.
Generally in a situation like this one would leave original authorship
intact (even my comments were preserved!).
> diff --git a/configure.ac b/configure.ac
> index 34b06f4..5649fe5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1896,7 +1896,6 @@ hw/xfree86/doc/man/Makefile
> hw/xfree86/doc/sgml/Makefile
> hw/xfree86/dri/Makefile
> hw/xfree86/dri2/Makefile
> -hw/xfree86/dummylib/Makefile
> hw/xfree86/exa/Makefile
> hw/xfree86/fbdevhw/Makefile
> hw/xfree86/i2c/Makefile
> diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
> index 09ee350..115d829 100644
> --- a/hw/xfree86/Makefile.am
> +++ b/hw/xfree86/Makefile.am
> @@ -14,12 +14,12 @@ endif
>
> DOC_SUBDIR = doc
>
> -SUBDIRS = common ddc dummylib i2c x86emu int10 fbdevhw os-support parser \
> +SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support parser \
> ramdac shadowfb vbe vgahw xaa \
> xf8_16bpp loader dixmods exa modes \
> $(DRI_SUBDIR) $(DRI2_SUBDIR) $(XF86UTILS_SUBDIR) $(DOC_SUBDIR)
>
> -DIST_SUBDIRS = common ddc dummylib i2c x86emu int10 fbdevhw os-support \
> +DIST_SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support \
> parser ramdac shadowfb vbe vgahw xaa \
> xf8_16bpp loader dixmods dri dri2 exa modes \
> utils doc
> diff --git a/hw/xfree86/dummylib/Makefile.am b/hw/xfree86/dummylib/Makefile.am
> deleted file mode 100644
> index 85a1d03..000
> --- a/hw/xfree86/dummylib/Makefile.am
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -# libdummy.a contains just those bits used in the server itself
> -# libdummy-nonserver.a contains additional routines normally found in the
> -# server for use in building the utilities like config tools
> -
> -noinst_LIBRARIES = libdummy-nonserver.a
> -
> -INCLUDES = $(XORG_INCS)
> -
> -AM_CFLAGS = $(DIX_CFLAGS) $(XORG_CFLAGS)
> -
> -if NEED_STRLCAT
> -STRL_SRCS = $(top_srcdir)/os/strlcat.c $(top_srcdir)/os/strlcpy.c
> -endif
> -
> -libdummy_nonserver_a_SOURCES = \
> - dixprivates.c \
> - fatalerror.c \
> - logvwrite.c \
> - $(STRL_SRCS) \
> - verrorf.c \
> - xalloc.c \
> - xf86allocscripi.c \
> - xf86addrestolist.c \
> - xf86drvmsg.c \
> - xf86drvmsgverb.c \
> - xf86errorf.c \
> - xf86errorfverb.c \
> - xf86getverb.c \
> - xf86info.c \
> - xf86msg.c \
> - xf86msgverb.c \
> - xf86opt.c \
> - xf86screens.c \
> - xf86servisinit.c \
> - xf86verbose.c \
> - $(srcdir)/../os-support/shared/sigiostubs.c
> -
> -EXTRA_DIST = README dummylib.h
> diff --git a/hw/xfree86/dummylib/README b/hw/xfree86/dummylib/README
> deleted file mode 100644
> index 4e27030..000
> --- a/hw/xfree86/dummylib/README
> ++
Re: xserver: Branch 'master' - 2 commits
On Thu, 2008-10-16 at 01:40 -0300, Tiago Vignatti wrote: > Aaron Plattner escreveu: > > As for the NVIDIA driver, you can use nm -D on it to see which symbols it's > > linked against. Also, I have a list of the strings we pass to LoaderSymbol > > at http://people.freedesktop.org/~aplattner/loadersymbol > > It was a bit out of date, so I updated it. > > disassemble the proprietary driver would not be illegal? nm isn't disassembly, it's just reading the ELF symbol table. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
On 16.10.2008 06:40, Tiago Vignatti wrote: > Aaron Plattner escreveu: >> As for the NVIDIA driver, you can use nm -D on it to see which symbols it's >> linked against. Also, I have a list of the strings we pass to LoaderSymbol >> at http://people.freedesktop.org/~aplattner/loadersymbol >> It was a bit out of date, so I updated it. > > disassemble the proprietary driver would not be illegal? Without discussing the general usefulness of these functions or discussing the legal-ness of disassembling (which might be a complicated matter), why do you need to disassemble the driver if you just want to know which symbols it's linked against? Roland ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
Aaron Plattner escreveu: > As for the NVIDIA driver, you can use nm -D on it to see which symbols it's > linked against. Also, I have a list of the strings we pass to LoaderSymbol > at http://people.freedesktop.org/~aplattner/loadersymbol > It was a bit out of date, so I updated it. disassemble the proprietary driver would not be illegal? -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
On Wed, Oct 15, 2008 at 04:38:03PM -0300, Tiago Vignatti wrote:
> Hi Aaron,
>
> Please, I don't want to be rude or something here but how can we argument
> that these functions above are _used_ by the sample server if none of its
> open drivers use it? This is questionable.
Hi Tiago,
The fact that the NVIDIA driver uses these functions is pretty much
irrelevant here: the functions are a useful part of the input/general
handler API. Removing useful API entry points just because no driver
happens to use them *today* is a bad idea because it prevents modules that
would like to use them in the future from working with current servers.
As for the NVIDIA driver, you can use nm -D on it to see which symbols it's
linked against. Also, I have a list of the strings we pass to LoaderSymbol
at http://people.freedesktop.org/~aplattner/loadersymbol
It was a bit out of date, so I updated it.
-- Aaron
> Aaron Plattner escreveu:
>> hw/xfree86/common/xf86.h |4 +
>> hw/xfree86/common/xf86Events.c | 84
>> +++--
>> hw/xfree86/loader/xf86sym.c|2 3 files changed, 62 insertions(+),
>> 28 deletions(-)
>> New commits:
>> commit 3fc4f40b6c6cb416c9dc4bdb35c91b4f32c03ccc
>> Author: Aaron Plattner <[EMAIL PROTECTED]>
>> Date: Sun Oct 12 16:08:26 2008 -0700
>> Restore xf86{Enable, Disable}GeneralHandler.
>> These were useful as part of the generic handler ABI, and are used
>> by the NVIDIA
>> driver.
>> This reverts part of commit
>> 50081d2dfb79878cb931a15c265f0d60698dfd39.
>> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
>> index 84ea633..fbbfc73 100644
>> --- a/hw/xfree86/common/xf86.h
>> +++ b/hw/xfree86/common/xf86.h
>> @@ -195,6 +195,8 @@ void xf86DisableInputHandler(pointer handler);
>> void xf86EnableInputHandler(pointer handler);
>> pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer
>> data);
>> int xf86RemoveGeneralHandler(pointer handler);
>> +void xf86DisableGeneralHandler(pointer handler);
>> +void xf86EnableGeneralHandler(pointer handler);
>> void xf86InterceptSignals(int *signo);
>> void xf86InterceptSigIll(void (*sigillhandler)(void));
>> Bool xf86EnableVTSwitch(Bool new);
>> diff --git a/hw/xfree86/common/xf86Events.c
>> b/hw/xfree86/common/xf86Events.c
>> index e91b332..babe45b 100644
>> --- a/hw/xfree86/common/xf86Events.c
>> +++ b/hw/xfree86/common/xf86Events.c
>> @@ -743,6 +743,20 @@ xf86DisableInputHandler(pointer handler)
>> }
>> _X_EXPORT void
>> +xf86DisableGeneralHandler(pointer handler)
>> +{
>> +IHPtr ih;
>> +
>> +if (!handler)
>> +return;
>> +
>> +ih = handler;
>> +ih->enabled = FALSE;
>> +if (ih->fd >= 0)
>> +RemoveGeneralSocket(ih->fd);
>> +}
>> +
>> +_X_EXPORT void
>> xf86EnableInputHandler(pointer handler)
>> {
>> IHPtr ih;
>> @@ -756,6 +770,20 @@ xf86EnableInputHandler(pointer handler)
>> AddEnabledDevice(ih->fd);
>> }
>> +_X_EXPORT void
>> +xf86EnableGeneralHandler(pointer handler)
>> +{
>> +IHPtr ih;
>> +
>> +if (!handler)
>> +return;
>> +
>> +ih = handler;
>> +ih->enabled = TRUE;
>> +if (ih->fd >= 0)
>> +AddGeneralSocket(ih->fd);
>> +}
>> +
>> /*
>> * As used currently by the DRI, the return value is ignored.
>> */
>> commit 2217d22a76cdb2460f9683a6bf74c7248612889d
>> Author: Aaron Plattner <[EMAIL PROTECTED]>
>> Date: Sun Oct 12 16:07:24 2008 -0700
>> Revert "xfree86: xf86{Enable, Disable}InputHandler can be static."
>> These were potentially useful as part of the input handler ABI,
>> even if nobody
>> currently uses them.
>> This reverts commit 278c11f01fbc6d6bd91c5a7127928c9ef5d29fca.
>> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
>> index 0956f9c..84ea633 100644
>> --- a/hw/xfree86/common/xf86.h
>> +++ b/hw/xfree86/common/xf86.h
>> @@ -191,6 +191,8 @@ xf86SetDGAModeProc xf86SetDGAMode;
>> void SetTimeSinceLastInputEvent(void);
>> pointer xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data);
>> int xf86RemoveInputHandler(pointer handler);
>> +void xf86DisableInputHandler(pointer handler);
>> +void xf86EnableInputHandler(pointer handler);
>> pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer
>> data);
>> int xf86RemoveGeneralHandler(pointer handler);
>> void xf86InterceptSignals(int *signo);
>> diff --git a/hw/xfree86/common/xf86Events.c
>> b/hw/xfree86/common/xf86Events.c
>> index a2c206e..e91b332 100644
>> --- a/hw/xfree86/common/xf86Events.c
>> +++ b/hw/xfree86/common/xf86Events.c
>> @@ -462,34 +462,6 @@ xf86ReleaseKeys(DeviceIntPtr pDev)
>> }
>> }
>> -static void
>> -xf86EnableInputHandler(pointer handler)
>> -{
>> -IHPtr ih;
>> -
>> -if (!handler)
>> -return;
>> -
>> -ih = handler;
>> -ih->enabled = TRUE;
>> -if (ih->fd >= 0)
>> -AddEnabledDevice(ih->fd);
>> -}
>> -
>> -static void
>> -xf86DisableInputHandler(pointer handler)
>> -{
>> -IHPtr ih;
>> -
>
Re: xserver: Branch 'master' - 2 commits
Hi Aaron,
Please, I don't want to be rude or something here but how can we
argument that these functions above are _used_ by the sample server if
none of its open drivers use it? This is questionable.
Aaron Plattner escreveu:
> hw/xfree86/common/xf86.h |4 +
> hw/xfree86/common/xf86Events.c | 84
> +++--
> hw/xfree86/loader/xf86sym.c|2
> 3 files changed, 62 insertions(+), 28 deletions(-)
>
> New commits:
> commit 3fc4f40b6c6cb416c9dc4bdb35c91b4f32c03ccc
> Author: Aaron Plattner <[EMAIL PROTECTED]>
> Date: Sun Oct 12 16:08:26 2008 -0700
>
> Restore xf86{Enable, Disable}GeneralHandler.
>
> These were useful as part of the generic handler ABI, and are used by the
> NVIDIA
> driver.
>
> This reverts part of commit 50081d2dfb79878cb931a15c265f0d60698dfd39.
>
> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
> index 84ea633..fbbfc73 100644
> --- a/hw/xfree86/common/xf86.h
> +++ b/hw/xfree86/common/xf86.h
> @@ -195,6 +195,8 @@ void xf86DisableInputHandler(pointer handler);
> void xf86EnableInputHandler(pointer handler);
> pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer data);
> int xf86RemoveGeneralHandler(pointer handler);
> +void xf86DisableGeneralHandler(pointer handler);
> +void xf86EnableGeneralHandler(pointer handler);
> void xf86InterceptSignals(int *signo);
> void xf86InterceptSigIll(void (*sigillhandler)(void));
> Bool xf86EnableVTSwitch(Bool new);
> diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
> index e91b332..babe45b 100644
> --- a/hw/xfree86/common/xf86Events.c
> +++ b/hw/xfree86/common/xf86Events.c
> @@ -743,6 +743,20 @@ xf86DisableInputHandler(pointer handler)
> }
>
> _X_EXPORT void
> +xf86DisableGeneralHandler(pointer handler)
> +{
> +IHPtr ih;
> +
> +if (!handler)
> + return;
> +
> +ih = handler;
> +ih->enabled = FALSE;
> +if (ih->fd >= 0)
> + RemoveGeneralSocket(ih->fd);
> +}
> +
> +_X_EXPORT void
> xf86EnableInputHandler(pointer handler)
> {
> IHPtr ih;
> @@ -756,6 +770,20 @@ xf86EnableInputHandler(pointer handler)
> AddEnabledDevice(ih->fd);
> }
>
> +_X_EXPORT void
> +xf86EnableGeneralHandler(pointer handler)
> +{
> +IHPtr ih;
> +
> +if (!handler)
> + return;
> +
> +ih = handler;
> +ih->enabled = TRUE;
> +if (ih->fd >= 0)
> + AddGeneralSocket(ih->fd);
> +}
> +
> /*
> * As used currently by the DRI, the return value is ignored.
> */
> commit 2217d22a76cdb2460f9683a6bf74c7248612889d
> Author: Aaron Plattner <[EMAIL PROTECTED]>
> Date: Sun Oct 12 16:07:24 2008 -0700
>
> Revert "xfree86: xf86{Enable, Disable}InputHandler can be static."
>
> These were potentially useful as part of the input handler ABI, even if
> nobody
> currently uses them.
>
> This reverts commit 278c11f01fbc6d6bd91c5a7127928c9ef5d29fca.
>
> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
> index 0956f9c..84ea633 100644
> --- a/hw/xfree86/common/xf86.h
> +++ b/hw/xfree86/common/xf86.h
> @@ -191,6 +191,8 @@ xf86SetDGAModeProc xf86SetDGAMode;
> void SetTimeSinceLastInputEvent(void);
> pointer xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data);
> int xf86RemoveInputHandler(pointer handler);
> +void xf86DisableInputHandler(pointer handler);
> +void xf86EnableInputHandler(pointer handler);
> pointer xf86AddGeneralHandler(int fd, InputHandlerProc proc, pointer data);
> int xf86RemoveGeneralHandler(pointer handler);
> void xf86InterceptSignals(int *signo);
> diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
> index a2c206e..e91b332 100644
> --- a/hw/xfree86/common/xf86Events.c
> +++ b/hw/xfree86/common/xf86Events.c
> @@ -462,34 +462,6 @@ xf86ReleaseKeys(DeviceIntPtr pDev)
> }
> }
>
> -static void
> -xf86EnableInputHandler(pointer handler)
> -{
> -IHPtr ih;
> -
> -if (!handler)
> - return;
> -
> -ih = handler;
> -ih->enabled = TRUE;
> -if (ih->fd >= 0)
> - AddEnabledDevice(ih->fd);
> -}
> -
> -static void
> -xf86DisableInputHandler(pointer handler)
> -{
> -IHPtr ih;
> -
> -if (!handler)
> - return;
> -
> -ih = handler;
> -ih->enabled = FALSE;
> -if (ih->fd >= 0)
> - RemoveEnabledDevice(ih->fd);
> -}
> -
> /*
> * xf86VTSwitch --
> * Handle requests for switching the vt.
> @@ -756,6 +728,34 @@ xf86RemoveGeneralHandler(pointer handler)
> return fd;
> }
>
> +_X_EXPORT void
> +xf86DisableInputHandler(pointer handler)
> +{
> +IHPtr ih;
> +
> +if (!handler)
> + return;
> +
> +ih = handler;
> +ih->enabled = FALSE;
> +if (ih->fd >= 0)
> + RemoveEnabledDevice(ih->fd);
> +}
> +
> +_X_EXPORT void
> +xf86EnableInputHandler(pointer handler)
> +{
> +IHPtr ih;
> +
> +if (!handler)
> + return;
> +
> +ih = handler;
> +ih->enabled = TRUE;
> +if (ih->fd >= 0)
> + AddEnabledDevic
Re: xserver: Branch 'master'
On 2008.10.10 14:07:36 -0400, Adam Jackson wrote:
> On Thu, 2008-10-09 at 22:52 -0700, Zhenyu Wang wrote:
>
> > diff --git a/hw/xfree86/ddc/xf86DDC.c b/hw/xfree86/ddc/xf86DDC.c
> > index 0d86776..ad8feef 100644
> > --- a/hw/xfree86/ddc/xf86DDC.c
> > +++ b/hw/xfree86/ddc/xf86DDC.c
> > @@ -249,6 +249,7 @@ xf86DoEEDID(int scrnIndex, I2CBusPtr pBus, Bool
> > complete)
> >
> > tmp = xf86InterpretEEDID(scrnIndex, EDID_block);
> > }
> > +xfree(EDID_block);
> >
> > if (tmp && complete)
> > tmp->flags |= EDID_COMPLETE_RAWDATA;
>
> Nuh-uh. The raw block is stashed in a pointer in xf86MonPtr:
oh, ajax, sorry about my mistake.
>
> xf86MonPtr
> xf86InterpretEDID(int scrnIndex, Uchar *block)
> {
> xf86MonPtr m;
>
> if (!block) return NULL;
> if (! (m = xnfcalloc(sizeof(xf86Monitor),1))) return NULL;
> m->scrnIndex = scrnIndex;
> m->rawData = block;
>
> /* ... */
>
> return (m);
>
> error:
> xfree(m);
> return NULL;
> }
>
> Reverted in master. xf86MonPtr needs a proper destructor function.
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Fri, 2008-10-10 at 14:12 -0400, Adam Jackson wrote: > Yeah, that sounds like something I'd say. I am not the release bitch > for 1.6 though. No strong feelings either way on the ABI number, > personally. I'm doing 1.6, and I don't care about ABI numbers either; the only rule we should make is that ABI numbers between two released servers reflect changes in the ABI that have occurred between those releases. For unreleased servers, we shouldn't make any guarantees. However, if you want to bump the number more often than each release, that's fine with me. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Fri, 2008-10-10 at 09:56 -0700, Aaron Plattner wrote: > On Thu, Oct 09, 2008 at 09:34:49PM +1030, Peter Hutterer wrote: > > ABI_XINPUT_VERSION was bumped with the MPX merge, thus 3 is already the > > correct version (server 1.5 has 2, btw.) Should we revert part of this > > patch? > > Sorry about that. I asked Adam if he wanted me to revert that part of it > after I realized I'd done that, and he said something along the lines of, > "nah, integers are cheap." I certainly wouldn't object if you reverted it, > but you should definitely get consensus from the release maintainer du > jour. Yeah, that sounds like something I'd say. I am not the release bitch for 1.6 though. No strong feelings either way on the ABI number, personally. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, 2008-10-09 at 22:52 -0700, Zhenyu Wang wrote:
> diff --git a/hw/xfree86/ddc/xf86DDC.c b/hw/xfree86/ddc/xf86DDC.c
> index 0d86776..ad8feef 100644
> --- a/hw/xfree86/ddc/xf86DDC.c
> +++ b/hw/xfree86/ddc/xf86DDC.c
> @@ -249,6 +249,7 @@ xf86DoEEDID(int scrnIndex, I2CBusPtr pBus, Bool complete)
>
> tmp = xf86InterpretEEDID(scrnIndex, EDID_block);
> }
> +xfree(EDID_block);
>
> if (tmp && complete)
> tmp->flags |= EDID_COMPLETE_RAWDATA;
Nuh-uh. The raw block is stashed in a pointer in xf86MonPtr:
xf86MonPtr
xf86InterpretEDID(int scrnIndex, Uchar *block)
{
xf86MonPtr m;
if (!block) return NULL;
if (! (m = xnfcalloc(sizeof(xf86Monitor),1))) return NULL;
m->scrnIndex = scrnIndex;
m->rawData = block;
/* ... */
return (m);
error:
xfree(m);
return NULL;
}
Reverted in master. xf86MonPtr needs a proper destructor function.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, Oct 09, 2008 at 09:34:49PM +1030, Peter Hutterer wrote: > Apologies for not spotting this earlier. > > On Mon, Sep 08, 2008 at 08:51:56AM -0700, Aaron Plattner wrote: > > commit 079625570d51e41569b73b2fd9237eb8f967f408 > > Author: Aaron Plattner <[EMAIL PROTECTED]> > > Date: Mon Sep 8 08:50:52 2008 -0700 > > > > Bump ABI major versions for the TryClientExceptions change from commit > > 883811c. > > > > > > #define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4) > > -#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(4, 1) > > -#define ABI_XINPUT_VERSION SET_ABI_VERSION(3, 1) > > -#define ABI_EXTENSION_VERSION SET_ABI_VERSION(1, 1) > > +#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(5, 0) > > +#define ABI_XINPUT_VERSION SET_ABI_VERSION(4, 0) > > ABI_XINPUT_VERSION was bumped with the MPX merge, thus 3 is already the > correct version (server 1.5 has 2, btw.) Should we revert part of this patch? Sorry about that. I asked Adam if he wanted me to revert that part of it after I realized I'd done that, and he said something along the lines of, "nah, integers are cheap." I certainly wouldn't object if you reverted it, but you should definitely get consensus from the release maintainer du jour. -- Aaron ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Apologies for not spotting this earlier. On Mon, Sep 08, 2008 at 08:51:56AM -0700, Aaron Plattner wrote: > commit 079625570d51e41569b73b2fd9237eb8f967f408 > Author: Aaron Plattner <[EMAIL PROTECTED]> > Date: Mon Sep 8 08:50:52 2008 -0700 > > Bump ABI major versions for the TryClientExceptions change from commit > 883811c. > > #define ABI_ANSIC_VERSIONSET_ABI_VERSION(0, 4) > -#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(4, 1) > -#define ABI_XINPUT_VERSION SET_ABI_VERSION(3, 1) > -#define ABI_EXTENSION_VERSIONSET_ABI_VERSION(1, 1) > +#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(5, 0) > +#define ABI_XINPUT_VERSION SET_ABI_VERSION(4, 0) ABI_XINPUT_VERSION was bumped with the MPX merge, thus 3 is already the correct version (server 1.5 has 2, btw.) Should we revert part of this patch? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
