Re: Kernel Module? On second thought...
RJ Judging from the large number of *flames* I got for suggesting it, These weren't flames. They were fairly kind explanations. A flame is something completely different -- you'll see if you hang around some more ;-) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
TR You really need some way to identify the XFree86 server as TR trusted. In Linux today, the only mechanism for doing that is TR suid root. I'm sorry to repeat what I've already said, but it isn't. It could very well be setgid xfree86, setgid hwaccess. Old SunOS had setgid kmem for ps and friends. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More details about a kernel module (by GPfault)
RJ An IOCTL shouldn't have any more overhead than reading or writing to a RJ file... Make this a hundred cycles (and you're probably flushing some caches somewhere). That's 0.1 us on a 1GHz CPU. The machine I'm typing this on can do 2 milllion short thin lines per second. That's 0.5 us per line. If you do one ioctl per short line, you're paying 20% overhead for the ioctl. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
On Fri, 17 Oct 2003, David Fox wrote: I think that the wisest approach is, instead of suggesting a kernel module to the XFree86 folks, you do two things. First, suggest a kernel module to the Linux folks that implements a protocol for accessing the resource you are trying to use. Then you go to the XFree86 folks and suggest a module to utilize that protocol in the X server. That's not any better. Unless someone comes up with a real problem that isn't just theoretical, and a real solution which requires or will work best being in kernel, and then implements it, and puts their money where their mouth is and proves that the solution not only works, but solves a real problem / really does improve performance, etc. they're not going to be taken seriously. You just aren't going to get anywhere with random hypothetical guesses as to what will be a magic performance boost until you crack out the tools to find performance hits, and write the code to fix them. If that can be done in XFree86 itself - great. If it can be done in the kernel, fine. If it can be done in XFree86 without requiring the kernel, and done as well or better in XFree86, even better, as then reliance on a random OS's kernel module is avoided. The kernel folk are going to tell you the same thing - that you dont just go and implement random code in the kernel and hope it fixes something. You find a problem, and you investigate potential solutions to it. If that involves the kernel - fine. Then you come to both the X developers and the kernel developers (of the particular OS kernel) and say something to the effect of: My following attached patch that implements foo in the Linux (or BSD or whatever) kernel, and an appropriate patch for XFree86 which uses this functionality optionally is attached. I've done performance tests on foobedoo in X and have determined it isn't possible to improve the performance of foobedoo without an additional kernel interface. My kernel interface implements this, and does so as cleanly as I could devise. The performance gain in fooblahblah applications is n% so this is definitely worth it and not just a negligible gain. I'm interested on hearing what other developers think of the patch I have created, and what feedback they can give so I can improve it, or try alternate methods. Or something to that effect. As I said before, making random suggestions to use kernel modules abstractly like it's a godsend for performance isn't going to get anyone anywhere, wether their intentions are extremely wll intentioned or not. So to take the whole topic out of the pie-in-the-sky land, and put it on the concrete ground: What _specific_ area of XFree86 performance are you (or anyone else) thinking needs improvement, what solutions have you investigated or even thought about which could improve this performance by modifying XFree86 itself, a driver, Mesa, or other userland code? If you do think the kernel might help for this problem, what steps have you taken to determine if that is truely reasonable, and have you tested your theory? Have you discussed that one small idea with other developers to see what they think about the alleged problem, wether it even really is a problem at all, how important it is, what other solutions there might be, etc. etc. etc. All of this lets stuff things in the kernel, because kernel code is automatically 2 times faster right? stuff gets boring fast. Show me the code. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: how to get a window's name which contains compound text?
wjd wrote: I works on redhat8,how can i get a window's name which contains a compound text in X11 program? I has tried: XGetWindowProperty(Display*,Window,XA_WM_NAME,0,(long)BUFSIZ, False,XA_STRING,actual_type,actual_format, nitems,leftover,return_data); it return Success,but return_data is empty, this problem also exist when i wnat to get _NET_WM_NAME property. Have you tried code like the bits recently checked in to xwininfo in the XFree86 CVS? Take a look at: http://cvsweb.xfree86.org/cvsweb/xc/programs/xwininfo/xwininfo.c.diff?r1=1.9r2=1.10 -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Updating NVidia documentation
On Fri, 17 Oct 2003, Alexander Shopov wrote: Hi guys, I am tryng to update the docs about nvidia chips in XFree86. I've checked out the sgml docs (module sgml) and the nv driver files (directory xc/programs/Xserver/hw/xfree86/drivers/nv) (HEAD branch) There is a man page in that directory. Is this the original or is there a sgml original somewhere else? xc/programs/Xserver/hw/xfree86/drivers/nv/nv.man is the NVIDIA driver documentation. That's what I edit. Also - I am wondering what is the connection between the xc/programs/Xserver/hw/xfree86/drivers/nv/nv.man file and the sgml/NVIDIA.sgml file. That file is 4 years old (XFree86 3.x days) and is not applicable. Alot of the files in that directory aren't applicable. I'm not sure why we keep this old documentation around. The MGA.sgml is 5 years old. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Betr: Re: xfs install on RedHat machine
On Thu, 2003-10-16 at 13:24, Mike A. Harris wrote: Anyway, the check for /usr/X11R6/bin/X to determine wether or not to start xfs has been removed for quite a while now, as it makes it difficult for people to start xfs, who don't run an X server on the same machine and just want to use xfs for network font serving. It seems like the best way to do it would be to still do the check for /usr/X11R6/bin/X, but only if TCP is disabled. You'd have to grep the configuration file to find this out, though. Don't know if that's worth it. Yes, this will probably upset the people out there who don't want xfs to start up if they're not using an X server. As I said above though, people can't have it both ways as we can't read people's minds. The initscript can be disabled like any other system service, so people who install xfs from now on, will have it enabled by default (and it has TCP disabled also by default), and those who don't actually want to use it or need it, can disable it themselves as an end user configuration customization. I feel this makes life the easiest for the largest amount of users out there, and that's one of our goals. ;o) -- Eamon Walsh [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Proposal for documentation patch - driver man pages, HWCursor, SWCursor
Hi guys, I checked driver man pages in xc/programs/Xserver/hw/xfree86/drivers/*/*.man Almost every driver implements the options: HWCursor, SWCursor however they are documented differently. From an end user perspective I would like: 1. Them being the same throughout docs 2. Them being as explicit as the best examples Should I prepare patches for this and enter them in Bugzilla? A patch per file? or a big patch containing all the changes? I will of course use MIT X11 license but are there any further intricate details I should know? (apart from http://www.xfree86.org/developer.html) Best regards: al_shopov ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: how to get a window's name which contains compound text?
Thank for your reply,i has run xwininfo directly,it told me this window has no name.I just try xprop,i find it will export correct window name,could you tell where to get the newest code of xprop? Thanks wjd wrote: I works on redhat8,how can i get a window's name which contains a compound text in X11 program? I has tried: XGetWindowProperty(Display*,Window,XA_WM_NAME,0,(long)BUFSIZ, False,XA_STRING,actual_type,actual_format, nitems,leftover,return_data); it return Success,but return_data is empty, this problem also exist when i wnat to get _NET_WM_NAME property. Have you tried code like the bits recently checked in to xwininfo in the XFree86 CVS? Take a look at: http://cvsweb.xfree86.org/cvsweb/xc/programs/xwininfo/xwininfo.cdiff?r1=1.9r2=1.10 -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel wjd [EMAIL PROTECTED] 2003-10-18 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Updating NVidia documentation
On Fri, 17 Oct 2003, Alexander Shopov wrote: Mark Vojkovich wrote: On Fri, 17 Oct 2003, Alexander Shopov wrote: xc/programs/Xserver/hw/xfree86/drivers/nv/nv.man is the NVIDIA driver documentation. That's what I edit. man page directly? Yes. It seems to me that this is standard ;-( Why is the other documentation in sgml and later translated to HTML, PS, man etc? Beats me. The nv.man gets translated into html and the installable man page. That file is 4 years old (XFree86 3.x days) and is not applicable. Alot of the files in that directory aren't applicable. I'm not sure why we keep this old documentation around. The MGA.sgml is 5 years old. OK. For now I have found the following docs on nVidia: xc/programs/Xserver/hw/xfree86/doc/README.NV1 Very out of date - NVidia NV1 / SGS-Thomson STG2000 Users, David McKay, 20th March 1997 xc/programs/Xserver/hw/xfree86/doc/README.NVIDIA Very out of date - Information for NVidia NV1 / SGS-Thomson STG2000, Riva 128 and Riva TNT and TNT2 Users, David McKay, Dirk Hohndel, June 25 1999 It seems it is built on top of README.NV1 xc/programs/Xserver/hw/xfree86/doc/sgml/NVIDIA.sgml This is the file that README.NVIDIA should be generated from. But the command corresponding to its generation in xc/programs/Xserver/hw/xfree86/doc/Imakefile is commented out. And of course: xc/programs/Xserver/hw/xfree86/drivers/nv/nv.man Mostly up to date. Only two options not documented. Any suggestions what I should do? Disregard everything but nv.man. The other docs are all circa XFree86 3.x. I think all the old docs should get deleted. Having wrong documentation lying around is confusing. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Updating NVidia documentation
On Fri, Oct 17, 2003 at 11:35:12PM +0300, Alexander Shopov wrote: Mark Vojkovich wrote: On Fri, 17 Oct 2003, Alexander Shopov wrote: xc/programs/Xserver/hw/xfree86/drivers/nv/nv.man is the NVIDIA driver documentation. That's what I edit. man page directly? It seems to me that this is standard ;-( Why is the other documentation in sgml and later translated to HTML, PS, man etc? Historically we had readme files (that's what is in SGML) for various drivers and other stuff. With the move to modular drivers in 4.0 we added man pages. It doesn't make sense to have the same information in both places. My personal preference is for man pages for drivers, and SGML/XML/whatever for other types of documents. Both types of docs get converted to HTML for our online documentation. They both end up in PS format (and PDF for 4.4), although in the case of the man pages it is one large document with all man pages. xc/programs/Xserver/hw/xfree86/doc/sgml/NVIDIA.sgml This is the file that README.NVIDIA should be generated from. But the command corresponding to its generation in xc/programs/Xserver/hw/xfree86/doc/Imakefile is commented out. Right. Out of date docs are not formatted or installed. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proposal for documentation patch - driver man pages, HWCursor, SWCursor
On Fri, Oct 17, 2003 at 02:15:20PM -0700, Tim Roberts wrote: On Fri, 17 Oct 2003 23:44:57 +0300, Alexander Shopov wrote: I checked driver man pages in xc/programs/Xserver/hw/xfree86/drivers/*/*.man Almost every driver implements the options: HWCursor, SWCursor however they are documented differently. Further, having two separate options is silly. It is a two-state switch: either the driver tries to use a HW cursor, or it always forces a SW cursor. What happens if you specify both, or neither? I'll bet different drivers come to different conclusions. The presence of both is probably historical. Some drivers have one, some both. The mga driver seems to define both, but only checks one. If you specify neither, the driver should default to whatever works best. That's the driver's call, but it should generally be HW cursor when available. Specifying both would be undefined in general, if both were specifying contrary behaviour. One way to handle the naming more uniformly might be to define the concept of option aliases, with, say, SWCursor aliased to NoHWCursor. That would make the specifying both behaviour well-defined too. It'd be nice to check driver options for consistency from time to time. It'd be even nicer if driver writers checked existing usage before making up new option names. A while ago we started documenting preferred option names and their behaviour in the xfree86/Registry file. There is also an xfree86/Options file that was added later. Back to the original point, the documentation of these options in the driver man pages should match how they are handled by the individual drivers. Specifically, the documented defaults may legitimately be different for different drivers. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [linux-usb-devel] USB keycodes Logitech Cordless Desktop Optical: (Was USB Multimedia Keyboards. Some keys do not produce keyevents)
On Fri, Oct 17, 2003 at 03:52:00PM -0400, Sheldon Lee-Wen wrote: Pardon my evilness in cross posting this, But I need to get a discussion going on how to resolve this problem. One lineak user went and tested his keyboard. Here is what he got. It does appear that for the keys that do not work, we have two situations. Either the kernel does not even see the key, i.e. nothing gets returned by either the kernel (in the form of an error written to the messages file), showkey -s, or xev. Or the kernel returns a Can't emulate rawmode for keycode message and neither X nor showkey -s see any output. You do not mention kernel version. These things are very sensitive to kernel version. If the kernel does not see the key at all, there is nothing the keyboard driver can do. The cases where the kernel complains Can't emulate rawmode for keycode ... while X and scancode -s do not see anything are for keycodes above 255. So far, keycodes have been 7-bit objects, and going to 8-bit is straightforward, but going past 8-bit requires updates to quite a lot of software. So, life is easier if one does not use large keycodes. The remaining codes are all OK. You have a keyboard and pressing a key produces some code. Use setkeycodes and loadkeys to assign some symbol or string. Or use some version of funkey or so to assign some action. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
