On Thu, Jun 26, 2003 at 03:35:21PM +0200, Robert Woerle wrote:can you point me to that code ?
Andrew C Aitchison schrieb:
On Thu, 26 Jun 2003, Cheshire Cat Fish wrote:hmm.... strange ... i can do exaclty that !!!
How do I go about reading a file from within my X driver. I want to read in a table of gamma correction values. If I use fopen() I get an unresolved symbol error.Drivers can't call libc functions, because drivers binaries are supposed to run on any operating system. XFree86 provides wrappers for some libc
Do I need to link to libc somehow? Or use something other than fopen()?
functions, but files are deliberately excluded (there is an exception
for input device drivers to talk to the device).
i am doing fopen() in an Input driver to reread my calibration data for the touchscreen
so i can do calibration on the fly with it ...
not doing a
#include <stdio.h>
did the trick , cause it seems that the X-source has his own fopen()
( unfortunatly i am missing a good way to signal the change of that data ... does anyone know how to SIGNAL a Input driver from a X-application )
my code looks like that : ( see also www.sourceforge.net/project/pacebook and browse the CVS for my touchscreen driver )
xf86PaceBookMisc(void)
{
FILE *fp;
fp = fopen ("/etc/X11/XF86Config","r");
do {
char *logs_old;
char logstring[1025];
logstring[0]='#';
fgets(logstring,1024,fp);
logstring[1025]=0; /* just to make extra sure */
if(logstring[0]=='#') continue;
if (strstr(logstring,"horizontalMax"))
...
You shouldn't count on video/input drivers always being able to open files directly. The only reason they can now is because of a limitation of the current loader design where all module types can access all exported functions. That's something I'm planning to change in the 5.0 time frame, if not sooner.
The "right" way to do this is either via the XInput extension (or an enhancement to it), or by looking at the message passing addition that Joe Moss recently added to the XFree86-Misc extension, and extending that to work with input drivers. This, by its nature, also eliminates the driver notification problem.
i would have done , if it wouldnt be so strange to get something committed into the X-source ...
The input device calibration problem seems to be such a common one that
I'm surprised nobody has been able to make the XInput extension handle
it cleanly.
maybe someone can post a current list of maintainers for the different drivers and sections of X
well ... i am no hardcore X- hacker , but i know how to survive and you are right that this is a major issueI guess everyone just wants to take the quick and dirty approach of communicating directly with the driver.
for touchscreen and probably some other Input drivers ...
I did that hack , because from my point of view X is very very weak in taking options on the fly ( or it is just not documented... or i just didnt found it )
Lagging these functionality , X misses a huge item of comfort for most of the users ...
it would be nice to get a function which is able to just reread the XF86Config at runtime and makes the values readable within the drivers ...
then anybody can use it or not in their drivers ...
the next thing i am really missing is a clear SIGNAL thing for input drivers where i can query the driver from within a X-client ...
Alessandro Rubini did that in a touchscreen driver from him ...
Grepping through the driver source, I do see that one or two video drivers do use this approach too. The "mga" driver even writes to a (fixed) temporary file name in a publicly-writable location, which looks like an open invitation for any user to overwrite arbitary system files. (I don't know who reviewed/committed that stuff.)
The sis driver goes one better and allows you to tell it which file to to overwrite :-(
There may be other places where this is misused too. The above two examples are from a quick grep, not a thorough audit.
This should give everyone an idea of how providing direct driver access to functions like fopen() can be innocently misused. The X server already provides an authenticated communication mechanism which should make it harder to cause inadvertant problems like this. Why not use it to implement a better method of doing these things?
David
-- _____________________________________ *Robert Woerle Linux & Customer Support* *PaceBlade Technology Europe SA* phone: +49 89 552 99935 fax: +49 89 552 99910 mobile: +49 179 474 45 27 email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> web: http://www.paceblade.com _____________________________________
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
