How to kick off a accelerate draw operation in source code
Hi all, I am writing a customerized graphic card driver in xfree86, and I refered to NV dirver, I can find that NVSetupForSolidLine and NVSubsequentSolidHorVertLine .. functions to manipulate the HW register, I wonder that it is just filling some data in the registers, I want to know when and which instruction kick off the draw operation. Please give me some clue. _ MSN Hotmail http://www.hotmail.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Alt+Tab make
I want to make a function like the Alt+Tab where various windows (Xwindow server) will come in front. The window maybe written in Qwidget, simple widget, or simple Xwindow Api. Any ideas or correspond source to see? Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
Juliusz Chroboczek wrote: AC (Of course, we do this somewhat on Solaris/sparc, Do you document the interface ? Partially - the generic interfaces all frame buffer drivers support are documented in the fbio(7) man page (available online at http://docs.sun.com/ ) and some frame buffer drivers document additional extensions in their man pages. For most of the newer frame buffers though, I believe the details of the more interesting bits are undocumented, private interfaces between the driver, the DDX module, and the OpenGL pipeline module. (All three of those come from our graphics hardware group, not the group I work in, which handles the device-independent parts of X for Solaris, so I don't know all the details.) -- -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: How to render multiple cursors?
Why would you want more than one pointer? and more importantly how would it be used? I wonder if you are not making life more difficult than it needs to be. Actually the more I think about the more I really want to know the answer to thoes two questions. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 4.4 reminder
This is a reminder that the XFree86 4.4 release is planned for mid December 2003, with 15 October 2003 being the final date for the submission of new features. See the release plans page on our web site for further details of the schedule http://www.xfree86.org/releaseplans.html. The 4.3.99.14 development snapshot scheduled for 10 October 2003 will the the last of the automatically generated snapshots in this release cycle. Subsequent snapshots will be generated manually as required until the 4.4 release. Automatically generated snapshots will resume again shortly after the release. As usual, check our development snapshots web page for information about the latest available XFree86 development snapshot http://www.xfree86.org/develsnaps/. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
Jakub Jelinek wrote: 1) could be done by some header which everything uses, doing #if defined HAVE_VISIBILITY_ATTRIBUTE defined __PIC__ #define hidden __attribute__((visibility (hidden))) #else #define hidden /**/ #endif and write prototypes like: void hidden someshlibprivateroutine (void); extern int someshlibprivatevar hidden; etc. I sent you a message about this before (in reference to libGL.so), but I never heard back from you. I think this is a very good idea! I would prefer it if __HIDDEN__ or HIDDEN or something similar were used. That makes it stand out more. Also, is there any reason to not have the symbols be hidden in non-PIC mode? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote: Looking at various /usr/X11R6/lib/lib*.so* shared libraries, I'm seeing lots of exported symbols which look like they are exported just because they cannot be static (as they are used by some other .o files in the same shared library, but never by anything outside). That is correct. If these could be classified (e.g. some _X* symbols in libX11.so.6, some _Ice* symbols in libICE.so.6 etc. might fall into this category), XFree86 could have smaller and faster shared libraries with less dynamic relocations, which would not need to set up PIC pointer so often and use less instructions to access shared library local variables (by bypassing GOT on some arches). ... and it would discourage applications from using symbols that aren't part of the published interfaces. I'd suggest starting with the library interface specs, exporting only those symbols that are documented as part of the interfaces, and seeing what applications break. If a signficant number of applications do break, that might suggest adjusting the specs to agree with common usage. I had plans of doing this with a linker version script, but it's still fairly low down on my todo list. From an API point of view, I think it would be better to specify the symbols that should be public, rather than identifying all non-statics that shouldn't be. It'd also be good if this could be implemented for as many of the platforms we support as possible. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 12:08:55PM -0400, David Dawes wrote: On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote: Looking at various /usr/X11R6/lib/lib*.so* shared libraries, I'm seeing lots of exported symbols which look like they are exported just because they cannot be static (as they are used by some other .o files in the same shared library, but never by anything outside). That is correct. If these could be classified (e.g. some _X* symbols in libX11.so.6, some _Ice* symbols in libICE.so.6 etc. might fall into this category), XFree86 could have smaller and faster shared libraries with less dynamic relocations, which would not need to set up PIC pointer so often and use less instructions to access shared library local variables (by bypassing GOT on some arches). ... and it would discourage applications from using symbols that aren't part of the published interfaces. I'd suggest starting with the library interface specs, exporting only those symbols that are documented as part of the interfaces, and seeing what applications break. If a signficant number of applications do break, that might suggest adjusting the specs to agree with common usage. I had plans of doing this with a linker version script, but it's still fairly low down on my todo list. From an API point of view, I think it would be better to specify the symbols that should be public, rather than identifying all non-statics that shouldn't be. It'd also be good if this could be implemented for as many of the platforms we support as possible. Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. In addition to that, at least non-static but not exported variables should be marked with X11_LIBRARY_LOCAL (or whatever other macro you prefer; __HIDDEN__ is IMHO bad since it is OS implementation namespace), for functions unless their address is taken it is much less important. Now, is there some easy way how can the initial .api/.sym files be created from the specs (exported headers or doc/specs or something else)? When that's done, I can surely first see what other symbols other XFree86 libraries need and then harvest some Everything install distribution for other symbols. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? Jakub ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-side functionality than we currently do; perhaps someday we'll have enough of that to be able to run non-root servers, at least on hardware that does memory-mapped I/O (the iopl system call is for root only). TR The key problem with this is that kernel modules are Linux-specific, and TR further often need to be kernel-version specific. XFree86 runs quite well TR in many non-Linux environments today. But that doesn't prevent it from using features specific to Linux when needed. Notice for example the use of the vm86old syscall in the Linux/i386 version of the int10 module, or the (optional) use of fbdev in quite a few drivers, or the future use of the /dev/input/event devices (hint, hint). Let alone the DRI. Implementing a kernel module might give access to more resources, like tighter console control, asynchronous accelerations, TR No, I don't think any of that is true. DMA? Smarter polling of FIFO status? Retrace interrupt? For this specific problem : I talked with M. Vojkovich about the yielding problem in that case, then we brought this to linux kernel guys (R. Russel and R. Love), both agreed to say that using sched_yield() will be really incorrect in 2.6, certainly to too much latency. They also both agreed to say that the solution is to use futex to sync the user space driver with the help of a kernel side which would poll the FIFO status (or whatever other conditions we want to wait for). They seemed to be interested in supporting that, so perhaps a joint effort could be successful on both sides so kernel can provide new services the X server could use. Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
X scheduler
Hi, Felipe and I are doing some research on interactivity on XFree86 when running with the Linux kernel 2.6. There was an interesting thread on the Linux Kernel Mailing List, where it was pointed [1] an interesting solution to adopt, suggested by Haoqiang Zheng: I have a kernel based solution to this question. The basic idea is: keep the processes blocked by X server in the runqueue. If a certain process (P) of this kind is scheduled, the kernel switch to the X server instead. If the X server get scheduled in this way, it can handle the X requests from this very process (P). By reading this message, it looks like the X scheduler really gives the processor to processes, but from what I understood by reading Efficiently Scheduling X Clients [2], written by Keith Packard, the XFree86's scheduler is used only to choose which process will have it's X requests processed. Can someone point me to a place where it's explained what the X scheduler does with the process that got scheduled? Thanks in advance, Lucas [1]http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8selm=oq3a.6x8.3%40gated-at.bofh.itrnum=12 [2]http://keithp.com/~keithp/talks/usenix2000/smart.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to render multiple cursors?
On Wed, 8 Oct 2003, Grant Wallace wrote: I earlier had a question regarding how to support multiple pointers. One reply to that was to write a Window Manager to handle this. I can see how the window manager can handle moving windows simultaneously and redirecting input to windows simultaneously. But I'm wondering how would one render multiple cursors from the window manager. It seems if it was just drawn on the root window then other windows would obscure it. Is there a way to draw a top level window that is transparent? Or is there some other trick to getting multiple cursors rendered that will always be on top? The SHAPE extension should let you have a window the shape of the cursor. Just make sure that all the cursor windows stay on top of the window stack. The 8+24 (and any other overlay) modes have two window stacks; don't forget to put the cursors in the top layer. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote: Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-side functionality than we currently do; perhaps someday we'll have enough of that to be able to run non-root servers, at least on hardware that does memory-mapped I/O (the iopl system call is for root only). TR The key problem with this is that kernel modules are Linux-specific, and TR further often need to be kernel-version specific. XFree86 runs quite well TR in many non-Linux environments today. But that doesn't prevent it from using features specific to Linux when needed. Notice for example the use of the vm86old syscall in the Linux/i386 version of the int10 module, or the (optional) use of fbdev in quite a few drivers, or the future use of the /dev/input/event devices (hint, hint). Let alone the DRI. Implementing a kernel module might give access to more resources, like tighter console control, asynchronous accelerations, TR No, I don't think any of that is true. DMA? Smarter polling of FIFO status? Retrace interrupt? For this specific problem : I talked with M. Vojkovich about the yielding problem in that case, then we brought this to linux kernel guys (R. Russel and R. Love), both agreed to say that using sched_yield() will be really incorrect in 2.6, certainly to too much latency. They also both agreed to say that the solution is to use futex to sync the user space driver with the help of a kernel side which would poll the FIFO status (or whatever other conditions we want to wait for). They seemed to be interested in supporting that, so perhaps a joint effort could be successful on both sides so kernel can provide new services the X server could use. Bye Manu This is more of a hack than a solution. I still see little utility in a kernel module. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to kick off a accelerate draw operation in source code
The Subsequent functions kick off the operations. You'll have to refer to your hardware documentation for how to do that for your hardware. Mark. On Thu, 9 Oct 2003, xiao john wrote: Hi all, I am writing a customerized graphic card driver in xfree86, and I refered to NV dirver, I can find that NVSetupForSolidLine and NVSubsequentSolidHorVertLine .. functions to manipulate the HW register, I wonder that it is just filling some data in the registers, I want to know when and which instruction kick off the draw operation. Please give me some clue. _ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Matthieu Herrb wrote (in a message from Tuesday April 1) Frank Liu wrote (in a message from Monday 31) I am trying to enable building shared lib for libXau, but got an error: ... gcc -o ./libXau.so.6.0~ -shared -Wl,-rpath,/usr/X11R6/lib -Wl,-soname,libXau.so.6 AuDispose.o AuFileName.o AuGetAddr.o AuGetBest.o AuLock.o AuRead.o AuUnlock.o AuWrite.o + rm -f libXau.so.6 + ln -s libXau.so.6.0 libXau.so.6 + rm -f ../../exports/lib/libXau.so.6 + cd ../../exports/lib /bin/sh: cd: /home/fliu/src/x/xc/exports/lib - No such file or directory apparently nobody created the directory ../../exports/lib I am wondering why I didn't get this error for building other shared libs such as those default libs that have shared enabled? Any ideas? Looks like a bug in many *lib.rules configuration files. The LinkBuildSonameLibrary() macro doesn't build the export/lib directory first. (The LinkBuildLibrary() macro used by non-shared libs does). It currently works with other shared libraries because the 1st built library is precisely libXau and its normally built non-shared only, so its build rule will indeed create the export/lib directory. If the 1st built library is shared and since the shared target appears 1st in Library.tmpl, the directory isn't created. This should be fixed. Better late then never. I just committed a fix for that. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: error building shared libXau
Frank Liu wrote (in a message from Tuesday Apr 1) more errors while final linking of XFree86, Xprt, Xnest, etc. eg: ... os/libos.a(auth.o): In function `LoadAuthorization': auth.o(.text+0x126): undefined reference to `XauDisposeAuth' auth.o(.text+0x135): undefined reference to `XauReadAuth' os/libos.a(xdmcp.o): In function `XdmcpRegisterAuthentication': xdmcp.o(.text+0x2ed): undefined reference to `XdmcpAllocARRAY8' xdmcp.o(.text+0x308): undefined reference to `XdmcpAllocARRAY8' ... If I build libXau and libXdmcp static, those errors will go away. do I need to add -lXau and -lXdmcp in the linking command line? Why static works? Because in the static case the libraries where on the command line as $(DEPLIBXAUTH) and $(DEPLIBXDMCP) - which are empty in the shared case. I'm going to fix that shortly too. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 04:55:25PM +0200, Jakub Jelinek wrote: On Thu, Oct 09, 2003 at 12:08:55PM -0400, David Dawes wrote: On Thu, Oct 09, 2003 at 02:05:47PM +0200, Jakub Jelinek wrote: Looking at various /usr/X11R6/lib/lib*.so* shared libraries, I'm seeing lots of exported symbols which look like they are exported just because they cannot be static (as they are used by some other .o files in the same shared library, but never by anything outside). That is correct. If these could be classified (e.g. some _X* symbols in libX11.so.6, some _Ice* symbols in libICE.so.6 etc. might fall into this category), XFree86 could have smaller and faster shared libraries with less dynamic relocations, which would not need to set up PIC pointer so often and use less instructions to access shared library local variables (by bypassing GOT on some arches). ... and it would discourage applications from using symbols that aren't part of the published interfaces. I'd suggest starting with the library interface specs, exporting only those symbols that are documented as part of the interfaces, and seeing what applications break. If a signficant number of applications do break, that might suggest adjusting the specs to agree with common usage. I had plans of doing this with a linker version script, but it's still fairly low down on my todo list. From an API point of view, I think it would be better to specify the symbols that should be public, rather than identifying all non-statics that shouldn't be. It'd also be good if this could be implemented for as many of the platforms we support as possible. Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. That sounds like a good approach. There are two ways that this is already done for some platforms. OS/2 and Cygwin use files like X11-def.cpp to list the exported symbols. Those lists might be a good starting point, but I suspect that more symbols are exported than are documented in the API specs. Also, X11R6.3 added export description files (like libX11.elist), together with scripts for a few platforms like Solaris, HPUX and AIX to process them. The .elist files are only provided for libX11 and libXt, and they simply export all globals. I don't know if the basic mechanism is worth reusing -- you should look at it and see what you think. They don't provide any useful information about what symbols should be exported for each library though. In addition to that, at least non-static but not exported variables should be marked with X11_LIBRARY_LOCAL (or whatever other macro you prefer; __HIDDEN__ is IMHO bad since it is OS implementation namespace), for functions unless their address is taken it is much less important. Now, is there some easy way how can the initial .api/.sym files be created from the specs (exported headers or doc/specs or something else)? When that's done, I can surely first see what other symbols other XFree86 libraries need and then harvest some Everything install distribution for other symbols. The *-def.cpp files are probably as good a starting place as any, since these are actually used for the OS/2 and Cygwin ports. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? What happens if you use the visibility attribute with a gcc 3.3 that doesn't have it enabled? If it's simply ignored, then it shouldn't be an issue. Otherwise, is there no pre-defined macro so that you can test for it in the source? If a gcc version check plus gcc feature macro check isn't an option, then I'd suggest adding an imake switch for now, and default it to off. Autodetection could be added to imake too. It'd be nicer if we had a mechanism for caching that information so that imake could do these tests once rather than hundreds of times per build. But nobody seems interested in the incremental approaches for achieving auto-config'd XFree86 builds :-(. But I digress. 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: X scheduler
On Thursday 09 October 2003 15:31, Lucas Correia Villa Real wrote: Hi, Felipe and I are doing some research on interactivity on XFree86 when running with the Linux kernel 2.6. There was an interesting thread on the Linux Kernel Mailing List, where it was pointed [1] an interesting solution to adopt, suggested by Haoqiang Zheng: I have a kernel based solution to this question. The basic idea is: keep the processes blocked by X server in the runqueue. If a certain process (P) of this kind is scheduled, the kernel switch to the X server instead. If the X server get scheduled in this way, it can handle the X requests from this very process (P). By reading this message, it looks like the X scheduler really gives the processor to processes, but from what I understood by reading Efficiently Sorry, I have just noticed the handle the X requests sentence on Haoqiang's suggestion. Anyway, wouldn't such solution (kernel based) avoid the computation of things not related to X requests? That is, since the X scheduler only treats X requests, if the X server is going to be scheduled instead of the process (P) then non-X requests will not be processed, and process (P) will hang, right? Or am I wrong? Does anybody wants to share their thoughts about this? Lucas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
