Bug 14735

Created attachment 14695 [details] [review]
0002-Fix-typo-emoveEnabledDevice-RemoveEnabledDevice.patch

(In reply to comment #1)
> Created an attachment (id=14695) [details]
> 0002-Fix-typo-emoveEnabledDevice-RemoveEnabledDevice.patch
> 

thanks. pushed as bbd274235f80cc8858f27d232f4218de2792250e. 


(In reply to comment #0)
>    Also a bit unsure about what would be the proper way to
> check for xf86_ansic functions, as adding a macro for checking
> the proper sdk header, and cut&pasting everywhere may not
> be the better way, so it checks XORG_VERSION_CURRENT, but
> that value has not yet been updated in git master...

I won't push this patch. Change all notions of xf86strdup to strdup seems to make more sense than this ifdef game. we don't compile on anything not having libc anyway.

> (In reply to comment #0)
> >    Also a bit unsure about what would be the proper way to
> > check for xf86_ansic functions, as adding a macro for checking
> > the proper sdk header, and cut&pasting everywhere may not
> > be the better way, so it checks XORG_VERSION_CURRENT, but
> > that value has not yet been updated in git master...
> 
> I won't push this patch. Change all notions of xf86strdup to strdup seems to
> make more sense than this ifdef game. we don't compile on anything not having
> libc anyway.

  Probably it makes more sense. There isn't much point in supporting
xf86_ansic now as there is only one loader, and the only reason one
could want to wrap libc is some sort of fake/weak security to avoid
binary only drivers trying to do more than they should (most likely
with super user priviledges)...

patch 2 was already applied in commit bbd274235f80cc8858f27d232f4218de2792250e

Created attachment 15172 [details] [review]
0001-Don-t-call-non-existing-function-and-compile-warning.patch

  This patch follows the model in video drivers, i.e. no reason
to have tests to check for the presence of xf86ansic, just don't
call xf86<libc> functions directly.

(In reply to comment #5)
> Created an attachment (id=15172) [details]
> 0001-Don-t-call-non-existing-function-and-compile-warning.patch
> 
>   This patch follows the model in video drivers, i.e. no reason
> to have tests to check for the presence of xf86ansic, just don't
> call xf86<libc> functions directly.

Paulo:

+#if 0
 	int            status_line;
+#endif

why?


+	ErrorF("xf86MagicReadInput: Touch Controller non inizializzato\n")

I think english would be more appropriate (I know it was spanish (?) before, but still).

(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=15172) [details] [details]
> > 0001-Don-t-call-non-existing-function-and-compile-warning.patch
> > 
> >   This patch follows the model in video drivers, i.e. no reason
> > to have tests to check for the presence of xf86ansic, just don't
> > call xf86<libc> functions directly.
> 
> Paulo:
> 
> +#if 0
>         int            status_line;
> +#endif
> 
> why?

  The code that uses it is #if 0'ed, so I followed pattern. Otherwise
gcc generates a (harmless) warning about an unused variabled.

> +       ErrorF("xf86MagicReadInput: Touch Controller non inizializzato\n")
> 
> I think english would be more appropriate (I know it was spanish (?) before,
> but still).

  It is italian, but my change was just a guess, as the call had the
format "<<%s[%d]>>", but no arguments. The other calls with
that format receive the expected __FILE__, __LINE__ arguments, so
maybe it would be a more proper patch to match driver author idea.

  The text should say: "Touch Controller not initialized" (but just
guessing like I would guess any other Latin derived language :-)

  I think the only other information I can find about it is the logs in
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/input/magictouch/xf86MagicTouch.c

Damnit, sorry I did not remember it was me who added it :-)

http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/CHANGELOG?rev=HEAD
doesn't have any more useful information either...

  I think it was posted to the patches list, and was one of the several
patches I applied, but never ever talked with the original author...

http://marc.info/?l=xfree86-devel&w=2 could be a good source to try to
find information about other old/unmantained input drivers...

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Created an attachment (id=15172) [details] [details] [details]
> > > 0001-Don-t-call-non-existing-function-and-compile-warning.patch
> > > 
> > >   This patch follows the model in video drivers, i.e. no reason
> > > to have tests to check for the presence of xf86ansic, just don't
> > > call xf86<libc> functions directly.
> > 
> > Paulo:
> > 
> > +#if 0
> >         int            status_line;
> > +#endif
> > 
> > why?
> 
>   The code that uses it is #if 0'ed, so I followed pattern. Otherwise
> gcc generates a (harmless) warning about an unused variabled.

fair enough.

> 
> > +       ErrorF("xf86MagicReadInput: Touch Controller non inizializzato\n")
> > 
> > I think english would be more appropriate (I know it was spanish (?) before,
> > but still).
> 
>   It is italian, but my change was just a guess, as the call had the
> format "<<%s[%d]>>", but no arguments. The other calls with
> that format receive the expected __FILE__, __LINE__ arguments, so
> maybe it would be a more proper patch to match driver author idea.
> 
>   The text should say: "Touch Controller not initialized" (but just
> guessing like I would guess any other Latin derived language :-)

Yeah, I thought about fixing it, but then again that would require to translate everything and I don't have the time for that now.


pushed as c616070ccdafd1dede1eb263bb480c7cf6cf6145.