Re: [Xpert]where do keycodes originate?
On Mon, Dec 10, 2001 at 03:13:44PM -0500, Paul Fox wrote: p.s. is there a public web-browsable copy of XFree86 source anywhere? i've been looking at the code at: ftp://ftp.x.org/pub/R6.4/xc/programs/Xserver/hw/xfree86/ which is clearly out of date. it doesn't have the above-quoted snippet, for instance, though i can see how it would fit in. The CVS repository is browsable at http://cvsweb.xfree86.org/. David -- David Dawes Email: [EMAIL PROTECTED] Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]where do keycodes originate?
On Tue, Dec 11, 2001 at 11:05:28AM -0500, Paul Fox wrote: yesterday in a fit of optimism i wrote: , doing some research on the logitech itouch keyboard has led me to the conclusion that my keyboard generates the same scancodes that it does, though with different keysyms. so i can probably make use the itouch xkb keyboard map pretty much directly. once i figure out how to configure _that_. :-) when i get home i'll turn off XKbdDisable, and work on getting an itouch config to work. hopefully i'll then be able to report success. alas, it was not to be. i think i don't understand how to configure the xkb stuff. i thought that to tell the server i have an itouch compatible keyboard that all i needed to do was this: Section Keyboard ProtocolStandard XkbRulesxfree86 XkbModelitouch XkbLayout us XkbOptions ctrl:swapcaps EndSection i still don't get any events from my internet keys though. is there something else i have to turn on or enable? the other odd thing is that the ctrl:swapcaps setting doesn't seem to work for me, making me think i really have screwed something up. bear in mind that i've been running in XkbDisable mode for years until trying this -- it's not that i just changed from pc101 to itouch. Are you seeing keypress/release events with xev -- even just the keycodes, with no keysyms? If not, then it's not going to work by playing around at the xkb level. It means that the key events aren't getting though, either because they're not being recognised by the XFree86 keyboard handling code, or because they're not getting through to it at all. David -- David Dawes Email: [EMAIL PROTECTED] Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]where do keycodes originate?
On Tue, Dec 11, 2001 at 11:32:06AM -0500, Paul Fox wrote: i still don't get any events from my internet keys though. is there something else i have to turn on or enable? the other odd thing is that the ctrl:swapcaps setting doesn't seem to work for me, making me think i really have screwed something up. bear in mind that i've been running in XkbDisable mode for years until trying this -- it's not that i just changed from pc101 to itouch. Did you try to run 'showkey' at the console, and press the internet keys on your keyboard? Did they then generate events there? Some USB keyboards yes, sorry, i didn't re-include the background info i went through yesterday. the keys work fine at the console. but something else occurred to me: does version 4.0.1a, which is what i'm running, have the necessary support for internet keys? when did the code snippet that david dawes quoted yesterday get added, relative to the release train? It should be there in 4.0.1. In that version you should even get a message in your X server log file about an Unreported Prefix0 scancode if the key events are getting through. David -- David Dawes Email: [EMAIL PROTECTED] Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cvs server problems?
On Fri, Jan 11, 2002 at 03:38:35PM +, mel kravitz wrote: I have been trying to cvs current sources from [EMAIL PROTECTED] for 2 days now with incomplete results xc/programs incomplete cvs ends with end of file message, also very slow server data transfer. It looks like our public cvs server was getting bogged down. I've reconfigured a few things to help handle the load better, and it seems to be working OK now. Someone else noted cvs hanging at the last file. It isn't unusual for there to be some delay between processing the last file and finishing -- it does some cleaning up then. David -- David Dawes Email: [EMAIL PROTECTED] Tungsten Graphics, Inc http://www.tungstengraphics.com Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 caused local DOS on linux
On Thu, Jan 10, 2002 at 04:12:11PM +0100, David Balazic wrote: the console ( keyboard+mouse+screen ) of a linux system can be locked up by a non-root user with the help of an xfree86 server. I first reported it to the linux kernel mailing list, but they pointed me here. Here are the relevant messages : My first mail : ---begin--- Subject: Simple local DOS Date: Wed, 09 Jan 2002 17:51:03 +0100 From: David Balazic [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] log in on some virtual terminal, then run the following line in a bourne type shell, like bash : X 21 | less A reboot fixes it. We want to reach windows level quality on desktop after all, don't we ? ---end--- Message from David S. Miller suggesting to take it to xfree86 people : ---begin--- Subject: Re: Simple local DOS Date: Thu, 10 Jan 2002 05:56:51 -0800 (PST) From: David S. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] From: David Balazic [EMAIL PROTECTED] Date: Thu, 10 Jan 2002 14:46:19 +0100 all this is off-topic on linux-kernel, non-root user locked up the console code. console code is part of kernel. it is a kernel topic. The real issue is that X has the console in an indeterminate state (it probably just saved the VGA state and is outputting probing information) but now it is blocked on terminal output due to the less. There is nothing the kernel can do about what X is up to. The suid wrapper for X can check if stdout/stderr is a pipe and refuse to run if it is. So really, it is in fact off topic for linux-kernel. Please take this to the xfree86 lists, I'm sure they'll be more than happy to fix it. Franks a lot, David S. Miller [EMAIL PROTECTED] ---end--- I guess a quick workaround would be to make the X server do that check (when started by a non-root user). Would another solution be to not block on stdout/stderr? David -- David Dawes Email: [EMAIL PROTECTED] Tungsten Graphics, Inc http://www.tungstengraphics.com Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]stdout a pipe?
On Wed, Jan 16, 2002 at 11:28:14AM -, sjb wrote: Hi guys, I had a big problem with my laptop earlier in the week and had to re-install Linux .. I also re-installed XF 4.1.99. When I log in as an ordinary user and type startx I get Stdout and/or stderr is a pipe and X refuses to start becuase of unsafe environment However, if I type xinit, everything starts properly. (If I log in as root, both startx and xinit work) It's not a big deal because I can start and run X, but does anybody know what the error message means and how I can fix it? This was added as a possible workaround for a problem that was reported here recently with the X server blocking because it's stderr output was going to less. I also set stderr to non-blocking for non-root users, so it may be OK to remove the pipe check. Could you send me the output of sh -x `which startx` ? David -- David Dawes Email: [EMAIL PROTECTED] Tungsten Graphics, Inc http://www.tungstengraphics.com Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]hostname - f sucks
On Mon, Jan 28, 2002 at 07:32:03PM +0300, root wrote: folks, the problem i`m adressing to is the fact that xfree86 4.2.0 (as does 4.1.0 and 3.3.6) makes an assumption that hostname accepts the -f otopin, which isnt necessarily true, (infact in most cases its not). It only makes this assumption on Linux. Are there Linux platforms where this isn't true? David -- David Dawes Email: [EMAIL PROTECTED] Tungsten Graphics, Inc http://www.tungstengraphics.com Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Thu, Jan 31, 2002 at 09:05:59AM +, Keith Whitwell wrote: Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Gareth Hughes wrote: The assumption was only made for experimental GATOS drivers. It is a practical one. More people come and ask: I upgraded to GATOS driver and DRI won't work anymore ! Answer: RTFM, upgrade drm driver. It's already been determined that: I just upgraded my kernel, and DRI won't work anymore! RTFM, upgrade your X server I just upgraded my X server, and DRI doesn't work anymore! RTFM, upgrade your kernel just doesn't cut it. You aren't allowed to do anything that requires a response of RTFM, upgrade ... Start thinking of alternatives... Gareth, the current driver is broken. If someone wants to use video capture they _need_ both GATOS 2d driver and GATOS drm driver, period. What's so wrong about upgrading ? Also, I can make drm driver work nice with older 2d drivers - as soon as someone will show me a way to tell the version of the 2d driver that is accessing the drm driver. Perhaps you should assume it is the older version until you know otherwise. I agree. I think it would be useful to have a way for the 2D driver to tell the drm driver what version it is, but if a 2D driver doesn't, you have to assume an older version. Older X servers and applications must work with newer kernel drivers. David -- David Dawes Email: [EMAIL PROTECTED] Tungsten Graphics, Inc http://www.tungstengraphics.com Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: libxml needs iconv.h ?
On Mon, Feb 18, 2002 at 02:07:56AM +, José Fonseca wrote: Do you really want a tool that does not understand complete syntax of the configuration file (let alone semantics) messing with Xserver configuration ? The are lot of scenarios were one would want that. Why should a tool for configurating the desktop size and depth worry about the Z axis mapping of the mouse? It doesn't need to know about it, even now, because we have a library for reading/writing the config file. The tool just needs to deal with the data structures that it's interested in. There are legitimate arguments for using XML, but I'm not sure that all of the arguments put forward fall into that category. Instead of making the XF86config a monster every configuration tool would had to be a even bigger monster.. Anyway, due to XML easy syntax there are very tiny XML parsers available, so this is not even an issue. I know that libxml2 isn't the smallest one around, but the code size is about three times that of the parser in XFree86. The difference of course is that libxml2 isn't single-purpose. For what is worth, I just want to say that IMHO the advantages of using XML heavily outweight its disadvantages. The number one disadvantage I see is the change, and I know that nobody is advocating making the switch overnight. The basic XFree86 config file format has existed for a LONG time, and XML wasn't available as an option when it was first developed. I'd really like to see a proposed DTD for an XML-based XFree86 config file. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: libxml needs iconv.h ?
a good idea. On the G400, for example, the second DAC is severely limited -- more so than with the G450. Of course, for every change we make to the defaults, there'll be people who don't like it. The tricky part is finding defaults that are OK for most cases. Just look at how many people complained about the change in 4.2.0 to the defaults for the windows keys on 104/105-key keyboards. About as many complained after the change as lobbied for it in the first place. There are therefore at least *four* things a poor user has to do to get it going, even ignoring xinerama (which I've put off reenabling, preferring to get work done to messing further with my config file any futher). We can/should do *alot* better, folks. We're being sloppy, hiding behind the fact the distribution vendors often clean up after us. The problem with the view that the distro vendors fix it, is that if you fall off the beaten path, you are currently in XF86Config file hell... And then we end up with tons of support questions soaking our time, along with alot of disgruntled people who say: this open source software stuff is for the birds. Ideally, on sane hardware (which the industry is slowly moving toward), the file can/should be empty, and the server work decently I *really* don't want to get a merit badge for editing my configuration file manually: I deserve one right now, unfortunately. 2) we need to bite the bullet and adopt a config file format that is both amenable to hand editing (which we should minimize by 1), and by tools (which is what most end users want and need). The current format is not: or we'd have to build tools to write the format, and such tools would have different API's than already being used for other system configuration metadata, which seems to be most often using XML these days. I don't see the current situation as something we can/should live with for any longer than absolutely necessary. Don't take this as a statement of love for XML; I'd have preferred a s-expression syntax, but due to the history of HTML coming from SGML, we end up with as the dominant way of storing such data. Sigh But it can be machine read and written, validated to a significant degree, and hand edited when necessary (and then validated). This seems like a win to me. - Jim -- Jim Gettys Cambridge Research Laboratory Compaq Computer Corporation [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A better X mouse cursor acceleration?
On Thu, Mar 14, 2002 at 12:15:58PM -0800, Michael Toomim wrote: Does anyone know of any programs, patches, drivers, etc. that allow for a better mouse cursor acceleration than what X does? The current method of multiplying the mouse's velocity by a constant whenever the motion exceeds a certain threshold isn't as nice and usable as the extremely smooth polynomial, exponential, etc. acceleration mechanisms that have been the standard in all the other modern windowing systems (windows, macos, etc.). Alternatively, does anyone know why the X mouse acceleration system sucks so much? :) The XFree86 mouse acceleration code has been using a different algorithm from this (a smooth one) for a few years when the threshold is set to 0. The traditional algorithm is still used when the threshold is non-zero. If you have a better alternative, feel free to submit a patch that implements it. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A better X mouse cursor acceleration?
On Fri, Mar 15, 2002 at 08:57:50PM +0100, Frank v Waveren wrote: On Fri, Mar 15, 2002 at 10:17:12AM -0500, David Dawes wrote: The XFree86 mouse acceleration code has been using a different algorithm from this (a smooth one) for a few years when the threshold is set to 0. The traditional algorithm is still used when the threshold is non-zero. Not quite true for my X server (XFree86 4.1.0) setting thresh to 0 gets no acceleration. That depends on what you also set the acceleration parameter to. If you try 'xset m 2 0' the acceleration should be obvious. The threshold == 0 algorithm in XFree86 since at least 4.0 uses a power function, with the power depending on the acceleration parameter. See the source code. xset m default (XChangePointerControl(dpy, 1, 1, -1, -1) however gets a nice smoothly accelerated cursor (which I'm using already, just never payed enough attention to it apparantly). It Which happens to result in the traditional algorithm being used, with defaults of 4 for the threshold and 2 for the acceleration. might be nice to document this, though I don't know where... Perhaps in man xset, which is where the average user will expect the info, but it really is just a question of how the server behaves I guess. The defaults are built-in to the X server. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Unresolved symbols in Xserver startup
On Mon, May 13, 2002 at 03:46:49PM -0600, Marc Aurele La France wrote: On Mon, 13 May 2002, Mike A. Harris wrote: New versions of the gcc compiler have an optimization called string merging which is enabled by default. The XFree86 module loader chokes on the ELF sections that this optimization adds to the ELF objects. To work around this XFree86 module loader limitation, you need to pass -fno-merge-constants to the linker when modules are being built. This can be done from host.def with: ModuleLdFlags -fno-merge-constants That should have a #define in front of it. This was automatically detected in later 4.1.0 CVS, and also in 4.2.0 CVS however it looks like someone removed the automatic checks in head CVS. No, it wasn't removed. But, it's possible that It looks like the relevant code in got isolated recently. I'll commit a fix. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mesa 4.0.2 by next XFree86 release?
On Sat, Jun 01, 2002 at 10:46:18AM +0700, Alexey Dokuchaev wrote: Hi! While there is stable Mesa version (4.0.2) lying around for a pretty long time already, is there any chance for us to see it merged in XFree86 by next release? ;-P The next XFree86 release will have the latest stable version of Mesa that's been integrated with the DRI code, so the answer is yes. Frankly, I see very little point of having Mesa3 in current version. The current XFree86 CVS has Mesa 4.0.1+. It was pointless including Mesa 4.0.x in XFree86 4.2 because the version of the DRI code that uses it was still in development at that time. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, Jul 15, 2002 at 01:11:17AM +0200, Lukas Molzberger wrote: Hello, in recent years many people were talking about Linux on the desktop. However, before there is any real chance that this could happen a few fundamential problems in XFree must be solved. These are: 1. XFree is far too slow. 2. What is presented on the screen should always be consistent (i.e. no flickering). (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) I look forward to seeing your solutions to these problems. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, Jul 15, 2002 at 01:56:41AM +0200, Xavier Bestel wrote: Le lun 15/07/2002 à 01:39, Nick Name a écrit : (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) Someone should write it. Indeed I think there are: I personally use debian, but Mandrake, Suse and RedHat users continuously say that their distribution can do everything graphically. Better yet, XFree shouldn't need configuration at all with modern hardware: config is just needed for some old un-probable chips, and some settings such as resolution, depth, etc. (which should be settable on the fly, BTW) I agree that configuration should be optional, and that's why I'm spending most of my free time on it at the moment. I'm hoping to have a first cut of this ready for the 4.3.0 release later this year. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Xpert digest, Vol 1 #2013 - 11 msgs
On Mon, Jul 15, 2002 at 02:43:04PM +0200, Xavier Bestel wrote: Le lun 15/07/2002 à 14:20, Mike A. Harris a écrit : what you are asking for is the RandR (Resize and Rotate) extention. This extension is implemented already, and support for it is available in the kdrive X server included with XFree86. The core server simply has not had RandR functionality added yet. It isn't funded development, so it will be done whenever someone cares to do it and has the time. I'm interested in working on it, but it hasn't been priority one for me yet. IIRC Mark said the API between the core server and the drivers doesn't allow for RandR to be implemented. Most of the Resize part could probably be implemented within the current driver API, but as Mark said, a fully featured implementation is probably better targetted for XFree86 5.0. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xf86execl problems
On Wed, Sep 04, 2002 at 03:12:35PM -0700, Rich Richardson wrote: I'm having a lot of trouble launching processes from a server-side dynamic module using xf86execl/execvp/etc -- I consistently get Resource not available errors. In general, is one allowed to do this sort of thing? If so, what might I be doing wrong (I'm pretty confident that I'm using exec correctly, since I've used the same block in other programs)... I'm not even sure why execl() is made available to modules. This and several other interfaces that are exported to modules shouldn't really be used by most existing classes of modules. Why do you need it? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 4.2.1 update release and Xlib security problem
XFree86 4.2.1 is now available. This is an update release, intended primarily to address some security issues. Release notes can be found at http://www.xfree86.org/4.2.1/RELNOTES.html, and other information can be found at http://www.xfree86.org/4.2.1/README.html and http://www.xfree86.org/4.2.1/Install.html. A summary of security updates can be found at http://www.xfree86.org/security/. XFree86 4.2.1 is available at ftp://ftp.xfree86.org/pub/XFree86/4.2.1/. The main security problem that prompted this release is a vulnerability in the Xlib modular i18n support that was added in XFree86 4.2.0. It makes it possible to cause a privileged Xlib client to load and execute arbitrary code. In the worst case this can be exploited locally to obtain a root shell. Releases of XFree86 prior to 4.2.0 do not have this problem. The XFree86 CVS trunk and xf-4_2-branch have this fixed as of today. A patch for 4.2.0 correcting just this problem can be found at ftp://ftp.xfree86.org/pub/XFree86/4.2.0/fixes/4.2.0-xlib-security.patch. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]i830/i845G updates
I've just committed a major rework of the i830/i845G support in the i810 driver. It's available from the XFree86 CVS trunk. If you had problems with the previous version, try this one. This version works best with the 2.4.19 kernel (or later). I've also done a little testing of this driver on FreeBSD with an 845G. FreeBSD's agp kernel module needs some patching to work with the 830 and 845G. I've got some further information about this at http://www.xfree86.org/~dawes/845driver.html. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830/i845G updates
On Tue, Sep 10, 2002 at 07:45:16PM -0700, Sottek, Matthew J wrote: David, You may want to consider changing the alloc_page to use pci_alloc_consistent() as is done in Alan Cox's version of the drm's. I changed the i810 one to do that in a patch sent to the drm list a couple weeks ago (Doesn't seem to be applied, I thought Jens was applying it). It looks like the alloc_page was reworked, but the pci_alloc_consistent() seems a cleaner way to go. (And potentially more correct, as I know that Alan changed it for a reason) Hi Matt, I saw your patch just after bringing in a related change from the 2.4.19 version of the module (to fix an oops). Switching to pci_alloc_consistent() is on my todo list. Maybe it's appropriate for the agpgart module to use it too? I haven't had a chance to look at how it works yet. I don't know how far back the pci* functions go. Might be a compatibility issue. Yes, that needs to be checked too. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830/i845G updates
On Thu, Sep 12, 2002 at 08:58:42AM -0600, Jens Owen wrote: Also, there are additional 3D fixes for the i845G in the DRI trunk. Unfortunately, there's more work to do to get the nightly snapshot to include the i845G: The 830/845G-specific code for all three components (2D, 3D, kernel module) is currently functionally equivalent in the DRI and XFree86 trunks. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830/i845G updates
On Tue, Sep 10, 2002 at 09:32:32PM -0400, David Dawes wrote: I've just committed a major rework of the i830/i845G support in the i810 driver. It's available from the XFree86 CVS trunk. If you had problems with the previous version, try this one. I've also committed XVideo support for the 845G. It may also work for some 830 configurations. One caveat with this is that there's a mode resolution/refresh rate limit above which the video overlay doesn't work. For the 845G that limit is 1280x1024@85Hz and 1600x1200@60Hz. For the 830 driving a CRT, the limit is approximately 1024x768@85Hz and 1280x1024@60Hz. The driver doesn't currently check for this. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]long long arithmetic in xserver modules
On Tue, Sep 17, 2002 at 04:49:43PM +0200, Helge Bahmann wrote: I am currently working on a loadable X server module and would like to use long long arithmetics in quite some places. During testing I always got An unresolved function was called! messages which were quite inexplicable to me, until I tracked it down to the symbol __divdi3, which gcc generates for my long long division (x86 architecture, gcc-2.95.4 on Debian Woody). This symbol is exported by the loader in the current XFree86. See xfree86/loader/xf86sym.c. In 4.2.0 it was only exported for IA-64 builds. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]OpenGL (Was: Work-around for busy-wait in XDGASetViewport)
On Mon, Sep 23, 2002 at 02:27:56PM +0200, Xavier Bestel wrote: Le lun 23/09/2002 à 00:20, Mark Vojkovich a écrit : People making games and such should move out of the DOS age and migrate to OpenGL. Will XFree 5 (or better, XFree 4.something:) support DRI on Xinerama ? For the general case, that's highly unlikely to happen in 4.x. Whether it happens for XFree86 5 depends on whether someone (anyone) decides to take it on. It's a difficult problem in general (see the Chromium project -- chromium.sf.net). The special case where both heads are viewports into a single framebuffer may be supported by some closed source drivers today, and likely at least one open source driver in the near future. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
On Thu, Sep 19, 2002 at 09:13:33AM -0700, Keith Packard wrote: The Resize and Rotate extension allows the root window to change size and rotation while the server is running and to switch the hardware among various depths. A preliminary implementation of this extension is included with current XFree86 bits, but only the kdrive-based X servers have ever implemented the necessary server-side pieces (for rotation and resize, but not for depth switching). I always wondered why depth switching was part of the RandR extension. I think that RandR should do what it's name suggests: resize and rotate, and the various depth switching and visual emulation problems/features be handled separately. Jim Gettys has been busily working on the device-independent and library portions of the Resize and Rotate extension for the last month and has completed it, and we're both hoping to get a chance to plug the necessary hooks into the regular XFree86 server to support resize immediately. That's definitely what is needed for RandR to be useful to most of this audience. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]MIME attachment handler in hypermail subtly corrupts attachments
On Fri, Sep 27, 2002 at 01:35:42AM -0500, Branden Robinson wrote: Maybe this is already common knowledge, but it surprised me. I was reviewing the patches I sent to [EMAIL PROTECTED], and noticed that a patch I submitted got corrupted. The message: http://www.xfree86.org/devel/archives/patch/2002-Sep/0008.shtml The attachment: http://www.xfree86.org/devel/archives/patch/2002-Sep/handle_vetoed_suspend.diff This is the troublesome line: + if (errno = EBUSY) Of course that shouldn't be an assignment...and, in fact, it wasn't in the mail I sent out. I think there is a bug in a MIME parser somewhere, probably in hypermail, that collapsed the == to a =. I don't know how the process of patch merging works, but this sort of corruption of attachments could really waste some time and introduce some subtle bugs. It looks like a problem with the mail archiver. The copy I have in my mailbox is as it should be (and that's what I always use). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]problem when compiling X
On Mon, Sep 30, 2002 at 07:12:30PM -0600, Marc Aurele La France wrote: I must admit to being rather surprised that *BSD doesn't have strtoull() yet (but allows long long). I was really hoping to avoid ugly #if's in this code. Oh well, such is life. This'll be fixed shortly. Some do. This from FreeBSD 4.4's strtoul(3)/strtoull(3)/strtouq(3) man page: NAME strtoul, strtoull, strtouq - convert a string to an unsigned long, unsigned long long, or uquad_t integer ... STANDARDS The strtoul() function conforms to ISO/IEC 9899:1990 (``ISO C89''). The strtoull() function conforms to ISO/IEC 9899:1999 (``ISO C99''). The BSD strtoq() function is deprecated. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cvs compile problems
On Tue, Oct 08, 2002 at 01:09:34PM +0100, Lars Hecking wrote:
cvs hasn't compiled for me in weeks, but only yesterday I found the time
to check why.
In programs/Xserver/hw/xfree86/drivers/i810/{i810,i830}_accel.c, various
symbols are undefined: I810_FRONT, I810_BACK, I830_FRONT etc. As I don't
know which include file should be included where, I cheated and copied
the missing defines into the resp. .c files ...
This should be fixed as of yesterday.
David
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: CVS Update: xc (branch: trunk)
On Thu, Oct 10, 2002 at 02:04:20PM -0400, James H. Cloos Jr. wrote: I think there is a bug in the ci of xc/nls/Compose/en_US.UTF-8. The cedilla changes look like this when run through utf2asc: dead_acute comma c : \u00E7 ccedilla dead_acute comma C : \xC3\u0087 Ccedilla dead_acute dead_acute c : \u00E7 ccedilla dead_acute dead_acute C : \xC3\u0087 Ccedilla dead_acute comma space : \u00B8 cedilla dead_acute dead_acute space : \xCB\u009D doubleacute Those are the only lines where a \x escape shows up rather than a \u escape. Ccedilla is of course \u00C7 and doubleacute is \u02DD. I've attached a patch below (gzip(1)ed to try to prevent any further encoding issues) that should fix those three lines. Thanks. I've just committed your fix. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]#define XprtServer NO and libXp
On Fri, Aug 23, 2002 at 02:30:57PM -0300, Frédéric L. W. Meunier wrote: Hi. Is there any reason to disable libXp if #define XprtServer NO is used ? I don't need the server but some applications require the library: # ./rp8_linux20_libc6_i386_cs2.bin ./rp8_linux20_libc6_i386_cs2.bin: error while loading shared libraries: libXp.so.6: cannot open shared object file: No such file or directory I compiled xf-4_2-branch. http://www.pervalidus.net/src/CVS/X11/xc/config/cf/host.def By default it's turned off when the Xprt server isn't built. You can turn it on by adding the following to your host.def: #define BuildXprintLib YES David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HW/SWCursor weirdness in a new i830 driver
On Wed, Sep 11, 2002 at 06:28:03PM +0200, Adam Kisiel wrote: Hi, I have just upgraded my X to the newest CVS and was delighted to see the much improved i830 driver. It works much better now, thanks! However I do encounter some wird problems with the mouse cursor. If I choose SWcursor - it is fine, though no DRI :( If I choose HWcursor - the cursor does not show up at all. But - in the applications which set their own cursor (e.g. Eterm 0.9.1) it is visible, but I guess it is not surprising since it is equivalent to software cursor. But, if I switch to a lower resolution, the cursor comes back, and stays visible even after switching back to the higher resolution. If you updated again since you originally sent this message, hopefully the HW cursor problem is now fixed. If not, let me know. Also - it seems that after X server terminates, it does not free the kernel module, which prevents consequent X servers from running. Also the kernel module cannot be un(re)loaded, insmod saying the resource is busy (even though no X-related process is running). Hmm, I haven't seen that problem. What are you running that uses the DRI? Does this still happen if you start the X server and exit it immediately without running any DRI clients? Since the driver got a major rewrite, I will ask the questions I asked some time ago: is there any chance of enabling 1400x1050 graphics mode? It is not returned as a valid mode by the VESA BIOS, so it would probably need a hard-wired code in the driver. Also - what about the TV-Out capability? The driver still sets video modes exclusively via the video BIOS, so unless the video BIOS has a 1400x1050 mode, it still won't work. If there is such a BIOS mode, and for some reason it isn't getting used, let me know. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mirrored display in X
On Fri, Oct 11, 2002 at 11:55:09AM +0200, Gabriel Ripoche wrote: Hi, I have a R505 Vaio laptop with a i830 chipset and am trying to have X display on an external screen as well as on my LCD panel. Right now I managed to have the display on both if the external monitor is plugged when I boot (this is actually automatic) but my external display frequency is 60Hz, which is a real pain on a 21. I haven't figured out a way to raise the external display frequency (played around with the XF86Config file but did not manage to get anything better) and the i830 chipset does not have the crt_screen option such as ATI. Has anybody figured out a way to have a decent frequency on an external display? (and optimally, a higher resolution, because my LCD panel is 1024x768, which is pretty big on a 21) Unfortunately the driver doesn't support driving two displays at different refresh rates. It should be possible to get a better refresh rate when using only the external display. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
On Fri, Oct 11, 2002 at 05:25:50PM +0200, Alexander Stohr wrote: Option DPMS BusID PCI:0:11:0 EndSection Section Device Identifier device1 VendorName ATI BoardName ATI Radeon Driver radeon Option DPMS Option AGPMode 2 BusID AGP:1:0:0 ^ Not sure this works either, but it probably doesn't matter as this is the primary device. What do you mean by 'not sure this works'? Are you referring to the AGP? The radeon card is agp, the rage card is pci. The agp entry works fine as a single head entry. AGP is an extension to the PCI specification. Therefore you get even AGP slots listed when running lspci. I know that PCI:1.0.0 is working on specific machines and it nicely selects the AGP board. I have never seen that you can replace PCI by AGP. Maybe it just works because your AGP display adapter is setup as the only remainder and therefore your section just applys. XFree86 treats AGP and PCI the same in a BusID string. I figured it was inevitable that someone would try AGP:x:y:z. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]dell c400 w/ i830m on freebsd w/ xfree86 4.2.1 using the vesa driver
On Fri, Oct 11, 2002 at 01:05:49PM -0700, Catherine Liao wrote: Hi there, I've spent the last two days trying to get X to run on my new Dell C400 laptop w/ FreeBSD. I was successful in getting X to start in 1024x768x8, but not higher. I've read that others have been able to get 1024x768x24, and I hope someone on this list might be able to help me out. My xf86config: http://catacus.com/~catz/docs/help/vesa_xf86config Log: http://catacus.com/~catz/docs/help/XFree86.0_log I did notice this entry in the log file: Total Memory: 13 64Kb banks (0M) What do I need to do to get X to see more memory? I've patched both i810_drv.o agpreg.h w/ the i810diff i810diff-2 patches. Here's the output from dmesg: http://catacus.com/~catz/docs/help/dmesg What am I missing? Any help is appreciated. Thanks! Try using the i810 driver instead of the vesa driver, but you'll likely need a more recent version than 4.2.1 (e.g., the current XFree86 CVS version). You'll also need a more recent version of the FreeBSD i8xx agp patches unless you're using FreeBSD 4.7. I have one at http://www.xfree86.org/~dawes/fbsd-830-agp.diff. All of this is necessary to allocate more video memory than your BIOS is reserving. I'm assuming that you don't have a BIOS configuration option to reserve more (some i830 laptops don't). If you do, you could just use that. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cvs won't build today
On Sat, Oct 12, 2002 at 04:34:15PM -0700, David Hawkes wrote: Hi: cvs will not compile for Solaris x86 due to xf86OSKbd.h (maybe recent mods) error line below: Thank you all In file included from sun_io.c:58: ../../../../../../programs/Xserver/hw/xfree86/os-support/xf86OSKbd.h:8: parse error before `pInfo' ../../../../../../programs/Xserver/hw/xfree86/os-support/xf86OSKbd.h:8: warning: function declaration isn't a prototype I'm committing possible fixes for this now. I'll see if I can do a Solaris test build soon. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 12:28:27AM +0200, Charl P. Botha wrote: On Mon, Oct 14, 2002 at 04:14:22PM -0600, Marc Aurele La France wrote: On Tue, 15 Oct 2002, Charl P. Botha wrote: This would mean that the bug is back and people will again have the stupid No, it doesn't. VT switch lockup. What would be the New and Improved Way(tm) way of explicitly re-enabling bus-mastering at RADEONEnterVT() time since xf86EnablePciBusMaster() has been deprecated? Just like the change notice says: When a PCI device is enabled, it's bus mastering is also enabled. This occurs before any driver code is executed. I'm running the DRI tree, so I can't test. However, we still don't know why these cards disabled bus mastering at VT switches (when it was very clearly enabled before the switch), so what guarantees that they won't still do this? Mike (Harris), do you have one of the affected cards running XFree86 HEAD? No, the X server restores changes is makes to the PCI state when it gives up control of the console, so if bus mastering wasn't enabled *before* the X server started, it won't be after VT switching away. Several drivers had bugs where they didn't re-enable it when switching back. Drivers shouldn't assume anything more about the HW state after returning from a VT switch than they would at startup, but unfortunately some still do... Marc's change means that drivers don't need to care about bus mastering being enabled because it will now be enabled automatically for PCI cards that are being used by the X server. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Core fonts issues [was: Problems with Type1 big fonts]
On Wed, Oct 23, 2002 at 08:13:10PM +0200, Juliusz Chroboczek wrote: DD Unless the old Type1 backend can unreservedly be replaced by the new DD FreeType2 backend, then it should be disabled, and maybe even a fake DD type1 font module created for the modular build so that existing DD configurations don't break. If there are still reasons for wanting the DD old backend, then it needs to be configurable, at least at build-time. DD If we want to provide more flexibility in allowing the user to control DD what font suffixes are handled by what backend, there would need to be DD some type of run-time configurability. I was looking into that when other things came up; I may very well be able to come back to this. Anyway, here's the plan I had. The idea would be to have a new interface, Bool FontFileRegisterRendererPriority(FontRendererPtr, int priority) where the existing FontFileRegisterRenderer interface in renderer.c is an alias for FFRRP with priority set to 0. Priority is an integer (positive or negative), and renderers with higher priority override renderers of lower priority. The Type 1 renderer would register with negative priority for both PFA and CID; in the absence of another CID renderer, it would render CID fonts, but PFA fonts would be handled by FreeType. FreeType would register with default priority for both PFA and TTF. X-TT would register with positivie priority for TTF. In a configuration in which all renderers are linked in, X-TT would handle TTF, FreeType would handle PFA, and Type 1 would handle CID. In a default configuration (no X-TT), both PFA and TTF are handled by FreeType. The advantage of that is that there are no new configuration mechanisms -- we simply leverage off the existing module loader. It's also easily extensible -- I expect to implement bitmap support in the FreeType backend after 4.3.0, and then you'll want the existing bitmap renderers to override FreeType if they're linked in. This would at least address the immediate issue, and it does need to be addressed before 4.3.0. The downside is that it's not completely flexible, not allowing for example to have TTF support using FreeType while using Type 1 for PFA. I don't think anyone cares. If someone does, then I guess they'll implement the more flexible solution. If anyone is interested in that, please let me know. DD Also, I'd really like to see some resolution to the separate FreeType DD and X-TT backends for TrueType fonts. As it is now, if someone chooses DD X-TT, they will still need the old Type1 backend for Type1 fonts DD regardless of other considerations. Is it still not possible to resolve DD the issues that led to two TrueType backends in the first place? Here's my personal perception. X-TT contains support for embedded bitmaps, which FreeType 1 didn't have. The new FreeType backend fully supports embedded bitmaps. X-TT also contains a number of features such as fake bolding and automagic slanting, collectively known as TTCap. These should be handled at the toolkit level in my opinion, and at any rate implementing new features in the core fonts system at this point is pretty much pointless. Still, users of X-TT have become accustomed to these features being made available at the server level, and would probably not accept them being taken away. I shall not implement the said features in FreeType, which I want to remain a small and clean piece of code. I shall also not integrate myself the (existing) patches that implement TTCap in the FreeType backend. If there is a person interested in doing that, I'll be glad to help -- but only if said person commits to maintaining the code for the indefinite future. The priority scheme should at least help a bit for now, but this issue still needs to be solved. There's always the drastic solution of just dropping one of them. Before anyone gets upset, that won't happen at least in the 4.3.0 timeframe, but I won't make any guarantees beyond that. At a minimum I'd like to see a clear summary of the issues from the point of view of an X-TT advocate. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Wed, Oct 23, 2002 at 08:19:31PM +0200, Juliusz Chroboczek wrote: AA Warning: font renderer for .pcf registered more than once For some reason that I don't understand, all renderers get registered twice in the modular server. FreeType is not at fault. I haven't seen any evidence of all renderers being registered twice. The bitmap module is always loaded by the core server, so also specifying it in the Modules section of the config file may lead to it being registered twice. I've added this warning to fontfile/renderer.c in the hope that somebody competent will end up looking into that. I modified that a little to only print the warnings for the first server generation -- otherwise you see them every time the X server recycles. I also modified the registration code to clear the list of renderers at the start of each new server generation. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 Bugzilla
On Wed, Oct 23, 2002 at 04:26:59PM -0700, Andrew P. Lentvorski wrote: On Mon, 21 Oct 2002, David Dawes wrote: This comes up from time to time. The bottom line is that having an XFree86 bug tracking system is of limited use unless the XFree86 developers use it. Since that's the group that it would impact the most, that's where the motivation for it should come from. BTW, is there an official Linux kernel bug tracking system? Yes. It's name is RedHat. ;) It seems IBM is setting something up too, but like Red Hat and other vendors, they're motivated by their business needs (which is fine). While the main development team may not be tracking bugs, the corporations which have significant Linux efforts (RedHat, IBM, etc.) are. The main development effort benefits from that infrastructure without acknowledging it. Red Hat, Debian, and others do track XFree86 bugs too. The results of that are a useful contribution. It works because someone at each those organisations does the filtering and followup, and passes on the relevant reports information and/or fixes to the XFree86 developers. Besides, what Linux does is not necessarily the right answer. Many people complain that Linux development is not scaling because the kernel complexity is exceeding the ability of one person to grasp it. And I hope that no one is suggesting that XFree86 should use BitKeeper ... No, nobody is suggesting that XFree86 should use BitKeeper (at least I hope they're not :-) It's quite understandable that the Linux kernel does though, since that's apparently what motivated it in the first place (but I don't want to turn this thread into a BK pro/con argument). The *BSD development teams provide examples of running and maintaining a project over long periods of time--even longer than Linux. These projects *do* have bug tracking systems. However, this is a political problem, not technical. Bug tracking will appear when lack of it annoys the development team. So, your best bet to get a bug tracking system implemented is simply to file lots of bug reports in the mailing lists until it annoys the developers. ;) A bug tracking system will appear when the developers feel that it would make their life easier. I don't know too many of us that have the time to go back and look over lists of bugs. Most of us find it easier to deal with them as they come in. If too many come in, more don't get dealt with. The only way I see a bug tracking system working right now is if someone makes the commitment to administer it. That means cleaning it regularly to keep it up to date (filtering/categorising reports, removing duplicates and out of date reports, tracking XFree86 commits and closing reports when they've been fixed, etc). That would allow developers to look through it when they wanted to without forcing the overhead of keeping it up to date onto them. If the developers are asked to do all of this, they won't, and the result will be a nice bug tracking system full of bugs marked unassigned. I don't see that as very useful. We could have taken that approach, but then everyone would be asking why their bugs haven't been looked at instead of why we don't have a bug tracking system. I'd prefer to not create the illusion. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Sat, Oct 19, 2002 at 12:04:43PM +0200, Charl P. Botha wrote: PS As things have been explained in this thread, it seems that X should not make any assumptions about hardware state when returning from VT. Would this mean that all Radeon (e.g.) hardware setup will have to be re-performed (e.g. re-installing the GPU microcode, performing all register outputs for setting up AGP, etc) after switching back from VT? If this is the case, Yes. Suppose something else that ran in the meantime installed different microcode, or made other changes to the HW state? that would be wonderful, as suspend/resume from disc/ram would just work without any ugly patches. Right. That's exactly how suspend/resume should work. It should be analogous to VT leave/enter. In fact, if you look at xf86PM.c, you'll see that by default LeaveVT gets called on suspend and EnterVT on resume. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Fri, Oct 18, 2002 at 07:37:03PM -0400, Mike A. Harris wrote: I can say 100% that this patch both for Radeon and Rage 128 has solved the lockup problems on over 100 users of Red Hat Linux (after that I stopped keeping track), and has caused no negative That fact is not in question. effects. I'm not sure if it is the correct solution to the problem, or the best solution, but it definitely was _a_ solution, and one certainly acceptable to me as it solves lockups that occured for numerous users for 9 months+. If the CVS code has a solution in it that makes the patch Charl created unnecessary, that's even better. Neither is that. If the CVS code does lockup however, then I think it makes sense to put Charl's patch back in. It doesn't, and continuing speculation to the contrary isn't helpful. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: I'm wondering if it's feasible for the kernel to route ACPI power management events to the corresponding APM events through /dev/apm (optionally, of course) for some sort of ACPI to APM backwards compatibility for some apps that use /dev/apm (like XFree86). Otherwise somebody will have to add /dev/acpi support to XFree86. It might be feasible to do this in user space too with a daemon that listens on /dev/acpi and delivers translated events on /dev/apm. Ultimately we probably want to add ACPI support to XFree86 so that it can take full advantage of what ACPI offers over APM. I think the original poster mentioned swsusp, which I thought was independent of APM and ACPI? I don't know what (if any) mechanism it uses to inform interested user-space applications that a suspend has been initiated. Either the X server needs to be informed about the suspend and resume so that it can do what needs to do, or have something else does get informed use chvt(1) to make the X server VT switch to a text console on suspend and switch back on resume. I think the chvt method is what people used before XFree86 had support for monitoring APM events. David Swsusp is totally independant of ACPI and APM, although it can be called by either. I am not sure if it fires an APM or ACPI event if these are enabled. Through the swsusp mailing list it has been esatblished that the prblem is with XAA, or more specifically with one XAA function, SolidTwoPointLine. If this is disabled everything works correctly. It apears that the hardware acceleration gets confused during the suspend/ resume cycle. Does it make a difference if you switch to a text VT before initiating a suspend? That's how XFree86 handles APM suspend/resume. With a correctly implemented VTEnter(), the driver should then reinitalise the hardware correctly when switching back to the X server after resuming. Some drivers don't to enough hw state initialisation in their VTEnter() function to handle returning from suspend. All of this assumes that the BIOS (and OS?) put the video hardware back into a sane text console state -- ideally the same state as after a normal system boot. If that doesn't happen, then there are likely to be problems. It has also been reported that when using the closed source driver, patched so that is does not block power management events, the 3d functinality does not work immediately after resume but will start working some time later. This would imply that there is a problem with the nvidia hardware after a resume that requires some form of reset. Another way to solve the problem is to start another Xserver on another display then kill it. This probably does the reset that should come though APM. Is there a way for a user space program to signal to the X server that a suspend is about to happen or that a resume has happend to enable this reset to be done more cleanly. Currently the X server only monitors the APM device for power management events. If swsusp can use some equivalent of apmd (or acpid), it should be possible to have that daemon force a VT switch on suspend, and switch back on resume (using chvt(1) as I suggested above). I think adding ACPI support to XFree86 is the way to go rather than a user space deamon. Kernel 2.4.20 is going to have a (almost) fully working ACPI implementation, the swsusp patch will still be needed for S4(suspend to disk), S1 (suspend to RAM) will work on some machines. What's the current state of acpid? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On Mon, Oct 21, 2002 at 01:18:19AM +0200, Michel Dänzer wrote:
On Son, 2002-10-20 at 23:57, Marc Aurele La France wrote:
On Sat, 19 Oct 2002, Boris wrote:
Hmm, Seems to be alot of problems in the CVS the last few days. Heres
the latest one.
[elided]
Recently upgraded to a 2.5.42+ kernel did we? If so, harp about this on
LKML. Let me know what the outcome is.
Actually, I just recompiled my 2.4.20pre11 kernel and redownloaded the
latest XFree cvs and I *still* get the same error when doing a make
install. Im running 2.4.20pre11, gcc 3.2, glibc 2.3.1.
Sounds like your /usr/include/{linnux,asm} links are still pointing into
the 2.5.43 kernel.
... but they shouldn't be links to kernel headers at all, but normal
glibc headers. There wouldn't have been a problem in the first place
like that.
What is the correct way to handle headers that defined ioctls?
David
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 Bugzilla
On Mon, Oct 21, 2002 at 03:54:30PM +0200, Erik Moeller wrote: Bugzilla is quickly becoming the standard bug tracking system for large open software projects. Originally developed by the Mozilla project, it is now used by KDE, GNOME, Apache, AbiWord, Red Hat Linux, Conectiva Linux, Gentoo Linux, Ximian, and many many others. XFree86, which is fundamental to any free desktop/workstation Un*x system, doesn't have an open bugtracking database (and, if some prior posts to this list are to be believed, not a closed one either). In my humble opinion as a user, this needs to change. In a prior post to this mailing list, Kurt Wall has already offered to set up a BTS for XFree86: http://www.xfree86.org/pipermail/xpert/2002-May/017211.html This comes up from time to time. The bottom line is that having an XFree86 bug tracking system is of limited use unless the XFree86 developers use it. Since that's the group that it would impact the most, that's where the motivation for it should come from. BTW, is there an official Linux kernel bug tracking system? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Mon, Oct 21, 2002 at 06:10:26PM +0100, Alan Hourihane wrote: On Mon, Oct 21, 2002 at 07:01:23PM +0200, Juliusz Chroboczek wrote: U Does anybody know any solution around the problem of X crashing with U Type1 big fonts ? The current Type 1 backend will no longer be the default in 4.3.0. The new Type 1 backend does not have this problem. There's a problem with this at the moment. If you build a static server you get two font renderers registered to deal with .pfa/.pfb fonts. Solution Juliusz - is it just to disable Type1 for static builds because it's too buggy ? Unless the old Type1 backend can unreservedly be replaced by the new FreeType2 backend, then it should be disabled, and maybe even a fake type1 font module created for the modular build so that existing configurations don't break. If there are still reasons for wanting the old backend, then it needs to be configurable, at least at build-time. Also, I'd really like to see some resolution to the separate FreeType and X-TT backends for TrueType fonts. As it is now, if someone chooses X-TT, they will still need the old Type1 backend for Type1 fonts regardless of other considerations. Is it still not possible to resolve the issues that led to two TrueType backends in the first place? As it is now, the first renderer registered for a suffix is the one that gets used. I'm not sure what order they're registered in right now for the static build. If we want to provide more flexibility in allowing the user to control what font suffixes are handled by what backend, there would need to be some type of run-time configurability. For the modular server this could probably be done fairly easily via the XF86Config file. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
On Tue, Oct 22, 2002 at 01:25:40AM +0200, Olivier Chapuis wrote: On Mon, Oct 21, 2002 at 04:54:26PM -0400, David Dawes wrote: On Fri, Oct 18, 2002 at 02:12:30PM -0700, Mark Vojkovich wrote: On Fri, 18 Oct 2002, Wojciech Kasprzak wrote: The application used to work under Linux 7.1. Has something changed in 7.3 with regard to colormap cell (pre?)allocations or locking it by some X clients? How can I find which clinets are allocating all the colors? On my laptop (Linux 7.1) I was able to test-allocate around 130 colors before running out of resources... Yes, we should put this in a faq or something. The render extension preallocates a large chunk of the default colormap in depth 8 in 4.2.0 (maybe in 4.2.1 too, I don't know). This behavior was removed in XFree86 CVS. You mentioned you were using the nvidia driver. If so, you can add the option NoRenderExtension to the XF86Config file to disable the render extension. This option is only supported by the nvidia driver. For other drivers you'll need to use XFree86 CVS (or maybe 4.2.1 if the fix made it in there). Since this bites a lot of people wanting to use legacy apps (probably one of the most common reasons for using depth 8 anyway), I think we need an option to allow this preallocation of colormap entries to be turned off. At least then people can choose what they need most -- Render support at 8-bit, or an untouched colormap. I just write a patch which does this today. I think also that it is a good idea to have an option which allows to control the colours that Render preallocate. I've added command lines / XF86Config options: -no-render-extension / NoRenderExtension -render-extension (for cancelling a NoRenderExtension option in XF86Config) -render-color-limit (int)cl / RenderColorLimit (int)cl I do not know if the naming is good. About the color limit arg cl it is a simple integer which replaces the default num of render/miindex.c which is equal to map_entries/(3 or 2). It is maybe better to allow only a few integers 0,1, ..., 6: clGreyScale PseudoColor 0 : default default 1 : 8 grey 8 grey 2 : 16 grey 2x2x2 cc + 4 grey (or 8?) 3 : 32 grey 3x3x3 cc + 8 grey (or 16?) 4 : 64 grey 4x4x4 cc + 16 grey (or 23?) 5 : 128 grey5x5x5 cc + 16 grey (or 32?) 6 : 256 grey6x6x6 cc + 32 grey (or 30) It is the first time I really read the code under Xserver so I am not sure I do the right things. Here what I do: I've added two new members to the ScreenRec structure: disableRender and renderColorLimit. In common/xf86Helper I've added a new function xf86SetRenderOptions(ScreenPtr) which setups these two members accordingly to the cmd line or config file option. Then, the driver should call xf86SetRenderOptions before it calls fbPictureInit. Is this implemented in a way that allows render to be enabled/disabled on a per-screen basis? If so, it's probably OK to put that stuff into the ScreenRec. Render is disabled in fbPictureInit: if disableRender, then fbPictureInit do nothing and return TRUE. It seems to me that this is ok: the driver should works as if it has no Render support (?). At least this works with the vesa and neomagic drivers. Your description sounds reasonable to me. One thing I am not really happy with is that we should add one line per driver. Maybe the two new members should be set in common/xf86Config.c (xf86HandleConfigFile). On the other hands, maybe some drivers will do not like to be compiled with RENDER, but run with renderDisabled? The way you're doing it the same as the way we currently handle enabling/disabling backing store on a per-screen basis. If it was a global option (like the Xinerama option) that affects all screens, it would be appropriate to handle it in common/xf86Config.c along with other ServerFlags options. As a per-screen option, the full set of collected options that will be applied to a screen isn't known in common/xf86Config.c. For example, it would be reasonable to have something like: Section Screen Identifier X Device ABC Device MonitorXYZ Monitor Subsection Display Depth 8 Option NoRenderExtension EndSubsection Subsection Display Depth 24 EndSubsection EndSection It isn't known until inside the driver's PreInit() function, where the screen's root depth is determined, which of the Display SubSection's will be used. Or you interested? Some comments? I'd be interested to see the patch. I don't know if anyone else has comments. Keith? Mark? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Tue, Oct 22, 2002 at 09:52:26AM +0200, Ducrot Bruno wrote: On Mon, Oct 21, 2002 at 05:14:28PM -0400, David Dawes wrote: On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: I'm wondering if it's feasible for the kernel to route ACPI power [...] Does it make a difference if you switch to a text VT before initiating a suspend? That's how XFree86 handles APM suspend/resume. With a correctly implemented VTEnter(), the driver should then reinitalise the hardware correctly when switching back to the X server after resuming. Some drivers don't to enough hw state initialisation in their VTEnter() function to handle returning from suspend. All of this assumes that the BIOS (and OS?) put the video hardware back into a sane text console state -- ideally the same state as after a normal system boot. If that doesn't happen, then there are likely to be problems. No difference. It is already a common trick for swsusp people. I don't see anything in the code that could explain why a perticular xaa extension is no more functionnal for this card. For me, VTEnter() from the nv driver seems to be correct. [...] Another way to solve the problem is to start another Xserver on another display then kill it. This probably does the reset that should come though APM. If VTEnter() is doing everything needed, I'm wondering why starting another X server then killing it solves the problem. If swsusp can use some equivalent of apmd (or acpid), it should be possible to have that daemon force a VT switch on suspend, and switch back on resume (using chvt(1) as I suggested above). I think adding ACPI support to XFree86 is the way to go rather than a user space deamon. Kernel 2.4.20 is going to have a (almost) fully working ACPI implementation, the swsusp patch will still be needed for S4(suspend to disk), S1 (suspend to RAM) will work on some machines. What's the current state of acpid? Nothing is done from swsusp to send power management notifications to user space before suspension. The same apply for ACPI. What's the use of acpid if it doesn't get any notifications before suspension? Is everything that needs to be done expected to be handled in the kernel? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
On Tue, Oct 22, 2002 at 08:08:24PM -0700, Keith Packard wrote: Around 22 o'clock on Oct 22, David Dawes wrote: -no-render-extension / NoRenderExtension -render-extension (for cancelling a NoRenderExtension option in XF86Config) Might shorten these to '-norender' and '-render'. However, I'd argue that Render should be considered a core extension and not be made optional at all. Applications like OpenOffice and Mozilla will not function reasonably without it, and (see below), it's impact can be mitigated or even eliminated, although some apps will probably produce unexpected results without any render colors in the default colormap aside from black and white. If it can be run in a mode where no colours other than black or white are allocated, then that'd be OK. It needs to be possible to have a configuration where legacy pseudocolor-only clients can run without interference. I can't think of too many reasons why people would choose to run in 8-bit mode other than to be able to run such clients. I note that we don't have a '-noshape' option available. That's because people don't complain about shape affecting the operation of legacy clients :-). colormap, except that the server won't do any nearest color matching. I suggest three models would be sufficient: -render-colors none - render uses only BlackPixel and WhitePixel -render-colors few - render gets 16(?) levels of gray -render-colors default - render gets a modest number as in current CVS 'few' mode will still be very useful in displaying AA text while consuming only a small part of the colormap, while 'none' eliminates any impact on the colormap while still permitting applications to accelerate non-AA client-side text. That sounds reasonable to me. It also simplifies the implementation (unless we want to be able to set these options per-screen from the config file). David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830 revisited (recent CVS build)
On Thu, Oct 24, 2002 at 06:57:01PM +0200, Martin van Es wrote: Hi, First I'd like to thank Jens for his patient answer to my last question :) I managed to successfully build a recent (23/10/2002) build of the X CVS tree and see great improvements on the support of my chipset (well, looking at the XFree86.0.log at least). This posting cuts 2 ways: My XFree86.0.log is included for developers as reference material. I hope it helps ;) Second: Can anybody comment on my questions? The size of my screen is now correctly recognised (1400x1050) but alas, the driver still resorts to the known VESA resolutions (1280 x 1024). Yes, because your video BIOS doesn't have a 1400x1050 mode, and the driver can only program modes that are provided by your video BIOS. It's unfortunate that vendors who ship 830-based laptops with 1400x1050 panels don't add such a mode to their video BIOS. Is that the long list of modes I see coming by now? They are all of the video BIOS graphics modes. What do the asterisks mean for some of the found modes? It means the mode matches the depth you're running at, and is available for use with your configuration. Is the line Not using mode 1400x1050 (no mode of this name) based on the fact that no mode called 1400x1050 passes by during the mode probing part? Or is it something I can help in the Configuration file? If it doesn't show up in the mode probing part, it isn't available. I read somewhere that if linux boots in a different mode than what I want to drive it under X, modelines are required in the XFConfig file? The monitor I choose (generic 1400x1050) does not add modelines in the XFConfig file... The X server has a set of built-in modelines -- all of the standard VESA modes, plus a few other common ones (including 1400x1050@60Hz and 1400x1050@75Hz). You only need to add modelines to the config files if you want to use modes that aren't built-in. For most applications the built-in set is sufficient. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CrtlAltKP_+/KP_- and cvs xfree
On Sat, Oct 12, 2002 at 10:37:31PM +0200, Arkadiusz Miskiewicz wrote: Hi, I'm using cvs version of xfree from today and CrtlAltKP_+/KP_- no longer works. Previously I was using cvs version of xfree from few weeks ago (before RandR merge). Config is exactly the same. Is there some app now to do that instead of ctrl+alt+,,+/-'' ? I committed a fix for this yesterday. Let me know if you still see problems with it. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Thu, Oct 17, 2002 at 02:21:13PM -0700, Mark Vojkovich wrote: On Fri, 18 Oct 2002, Brad Hards wrote: On Fri, 18 Oct 2002 05:35, Mark Vojkovich wrote: The nv driver doesn't know (and can't know) anything about suspend events. It's handled entirely by the bios and there is no mechanism for XFree86 to get these ACPI events from the kernel. Subsequently, the bios will mess up the nv driver's state and the nv driver won't know that it needs to be reinitialized. You have to VT switch to clean things up. I think the only solution to this problem is to have ACPI support in the kernel and have the events routed to /dev/apm (which XFree86 supports) or to some other device and have XFree86 add support for that device. Tim Hockin wrote a acpid (on sourceforge.net) that can take ACPI events from the kernel ( via /proc/acpi/event ) and runs things in userspace. That is a potentially useful approach in this case. I see something like this (generalised to handle many other events), along with the current Linux hotplug style approach, as the path to make X work in dynamic hardware and networking environments. I'm wondering if it's feasible for the kernel to route ACPI power management events to the corresponding APM events through /dev/apm (optionally, of course) for some sort of ACPI to APM backwards compatibility for some apps that use /dev/apm (like XFree86). Otherwise somebody will have to add /dev/acpi support to XFree86. It might be feasible to do this in user space too with a daemon that listens on /dev/acpi and delivers translated events on /dev/apm. Ultimately we probably want to add ACPI support to XFree86 so that it can take full advantage of what ACPI offers over APM. I think the original poster mentioned swsusp, which I thought was independent of APM and ACPI? I don't know what (if any) mechanism it uses to inform interested user-space applications that a suspend has been initiated. Either the X server needs to be informed about the suspend and resume so that it can do what needs to do, or have something else does get informed use chvt(1) to make the X server VT switch to a text console on suspend and switch back on resume. I think the chvt method is what people used before XFree86 had support for monitoring APM events. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Changing ctrl-alt-bckspc to ctrl-alt-delete
On Thu, Oct 17, 2002 at 02:29:19PM -0700, Mark Vojkovich wrote:
On Thu, 17 Oct 2002, Boris wrote:
I have found the file, What line would I have to change and what do I have
to change it too?
You'll have to figure out how things work and investigate that.
You can see where the current ctrlaltbs is handled. It looks
like:
if ((ModifierDown(ControlMask | AltMask)) ||
(ModifierDown(ControlMask | AltLangMask)))
{
switch (specialkey) {
case KEY_BackSpace:
if (!xf86Info.dontZap) {
#ifdef XFreeXDGA
DGAShutdown();
#endif
GiveUp(0);
}
break;
[...]
It *might* be as easy as adding or changing the case statement to
include the delete key.
Yes, that should work.
It'd be nice to make this configurable, and I'm sure that a patch
to do that would be welcome.
There may be other ways to do this via configuring the XKB
extension. But I know next to nothing about XKB.
It's currently intercepting key events before they get passed up out of
the DDX. I'm not sure how feasible it would be to intercept them after
they've been converted into X keysyms, but that might offer a more
configurable solution.
David
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Fri, Oct 18, 2002 at 07:42:23PM -0400, Mike A. Harris wrote: On Thu, 17 Oct 2002, Marc Aurele La France wrote: The problem WAS that this re-enabling did not always take place before Marc's changes, which is why we added the explicit call to do this. I've checked the code in current XFree86 CVS, but would very much like to know (just for interest's sake) WHERE exactly the PCI enable (or whatnot) is called from that re-enables bus mastering after a VT switch. The question on my, and David's, mind is whether or not bus mastering was enabled on server entry. I can't say for every reported case, but I can say that on the cases I examined personally, that the video hardware had Bus Mastering enabled prior to the X server being started (lspci -vvv), as well as while the X server was running. Switching to a VT and doing lspci -vvv then showed bus mastering disabled. OK, I just tested this with a stock XFree86 4.2.0 build, and lspci -vvv shows that the bus master state when switching to another VT is always the same as that before the X server was started. I tried this with a Radeon 7500 and a PIII motherboard with a 440BX chipset, running RH 7.2 with the default kernel. Bus mastering was on by default, and never got turned off when VT switching. If I turned it off manually, then it got turned on by the radeon driver, and back off at VTLeave. It then remained off because the unpatched driver didn't turn it back on at VTEnter. If the X server doesn't restore the PCI state at VTLeave and X server exit, it's a bug. So, if you do reproduce it again, it would help to find out exactly why it's happening. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: r200 and libxaa
On Mon, Oct 21, 2002 at 08:56:57AM -0400, Kevin E Martin wrote: I admit I didn't think through all of the implications of the XAA change, but, rather, I put the new items in the XAAInfoRec where they logically should go -- next to the functions they effect. Michel caught my oversight and has fixed the problem, but only in the DRI CVS tree. When Michel sends patches back to XFree86, I will incorporate them. And, I've asked him in private e-mail just last week to do exactly that. I have not fixed this problem in the XFree86 tree yet since I'm waiting either for a DRI/XFree86 resync or for patches to be sent in. In general, this is one of those DRI CVS tree and XFree86 CVS tree have greatly diverged problems, which will hopefully be fixed soon when the two trees are resynced. This resync is currently being planned and will hopefully happen sometime soon. Compatibilty problems like this should be fixed as soon as they're found rather than waiting for resyncs. Otherwise, as in this case, they cause mysterious problems for others trying to use the current XFree86 CVS. Mark committed the relevant fix last night. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
On Fri, Oct 18, 2002 at 12:12:03AM +0200, Charl P. Botha wrote: On Thu, Oct 17, 2002 at 02:51:57PM -0600, Marc Aurele La France wrote: The question on my, and David's, mind is whether or not bus mastering was enabled on server entry. According to lspci, it was definitely enabled. I'm reluctant to prolong this thread any further, but was bus mastering enabled after a clean reboot and before running any X server? Whatever it was at this time is how the X server should leave it after VT switching away and when exiting. Please also excuse me for getting a little concerned at your changes and the very cryptic CVS log message that you took time to submit. I thought the message very descriptive, and the change a good idea after running into exactly the same bug with the i830/i845G support recently. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Tue, Oct 22, 2002 at 12:59:34AM -0400, James H. Cloos Jr. wrote:
David == David Dawes [EMAIL PROTECTED] writes:
David Unless the old Type1 backend can unreservedly be replaced by
David the new FreeType2 backend, then it should be disabled, and
David maybe even a fake type1 font module created for the modular
David build so that existing configurations don't break. If there
David are still reasons for wanting the old backend, then it needs to
David be configurable, at least at build-time.
I beleive the old type1 backend is still required for type1 cid fonts.
It would be useful to have an easy way of compiling it w/ the moral
equivilent of:
--- t1funcs.c.~1~ Mon Feb 18 15:51:57 2002
+++ t1funcs.c Tue Oct 22 00:57:09 2002
@@ -1434,16 +1434,20 @@
FontRendererRec CIDRendererInfo[] = {
{ .cid, 4, NULL, CIDOpenScalable,
+NULL, CIDGetInfoScalable, 0, CAPABILITIES },
+ { .CID, 4, NULL, CIDOpenScalable,
NULL, CIDGetInfoScalable, 0, CAPABILITIES }
};
#endif
-#ifdef BUILDCID
+#ifndef BUILD_ONLY_CID
+# ifdef BUILDCID
FontRendererRec Type1RendererInfo[] = {
-#else
+# else
static FontRendererRec renderers[] = {
-#endif
+# endif
{ .pfa, 4, NULL, Type1OpenScalable,
NULL, Type1GetInfoScalable, 0, CAPABILITIES },
{ .pfb, 4, NULL, Type1OpenScalable,
NULL, Type1GetInfoScalable, 0, CAPABILITIES }
};
+#endif
so that it will load .cid and .CID files but leave .pfa or .pfb for
the ft2 driver.
A run-time method for assigning font file suffixes to backends would
take care of this too, at least for the XFree86 server (and maybe also
the font server?). Is anyone interested in looking into that?
For other servers, it's easiest to handle it at build time, and it would
be useful to imake switches to determine common useful combinations like
this. Any takers for implementing this?
David
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: r200 and libxaa
On Mon, Oct 21, 2002 at 12:30:24PM +0200, Michel Dänzer wrote: For your reference, here's what I committed to DRI CVS. The check for the XAA minor version could probably be done more elegantly in XFree86 CVS though. Adding checks like that to the XFree86 CVS version isn't encouraged, because compatibility in that direction isn't guaranteed (and where do you draw the line with regard to making new driver modules work with old X servers and other modules?) The xf86GetModuleVersion() function was added after 4.2 to make this easier in other environments though. There's an example that uses it in the i810 driver in the DRI CVS, but I omitted that check for the version in the XFree86 CVS. Compatibility in the other direction is important though, and moving the new struct fields to the end should address that in this case. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: backporting intel 845 2d
On Fri, Nov 01, 2002 at 05:31:17PM -0800, Michael Cardenas wrote: I have backported the 2d driver of the intel 845G driver for our upcoming release of lindowsOS. In our testing, we have come across a bug which was fixed in a later series of patches. The specific bug is that the 845G driver doesn't respect the refresh rates specified in the xf86config file. From looking at the cvs commit list, I see that it was fixed in a later series of patches that include 3d support. I'm not sure what you mean by the 2d vs 3d distinction. I would like to ask if it would be possible to separate the fix for refresh rate handling from the larger 3d patch, as we don't have the time to work on the entire 3d patch (which is really two large patches) and I'm not inclined to add that much possible instability to our upcoming release. If you're referring to the changes I committed in November (which fix refresh rate handling amongst other things), then they're not easily separated out. I ended up rewriting significant parts of the 2D driver, including the mode handling. I don't have the time (or inclination) to go back to the old version of the driver. It's a can of worms, which is why I opted for the rewrite in the first place. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Proposal for mouse speed acceleration settings
On Fri, Nov 01, 2002 at 11:58:31PM -0800, J. Imlay wrote: I am just a casual reader on this list so I could be entirly wrong about all this. I've read the thread that you started last spring, and I've been following this one, and I sympathize with you on the problems with the acceleration in X (it's down right unusable IMHO) but what I'm missing is what you are actually trying to get at? The issue was brought up last spring, and appearantly nothing was done about it. And the problem doesn't seem to be lack of a patch it's just that someone (a mystery to me as well) doesn't seem to like to apply patches from anyone but ... well I don't know. Only a few of the inside guys get to change the code at all. I think the problem in this particular case is lack of agreement about the nature of the pointer accleration problem and/or its solution. If those interested in solving the problem can discuss it here and come to some agreement on what the true nature of the problem is, and come up with a fix that solves it, then the code will get changed. Churning the code by committing each personal preference solution that gets submitted doesn't solve the problem (and that's how I'd characterise most of the submissions that actually contained patches that I've seen on this topic so far). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Patches in limbo - was Re: [Xpert]Re: Proposal for mouse speed acceleration settings
On Sat, Nov 02, 2002 at 10:31:10AM +, Stephen Davies wrote: So those who send patches should expect some feedback or questions as to our code. I submitted a tdfx driver patch on 7th Oct: Your submission to [EMAIL PROTECTED] has been assigned the sequence number A.1297. I would have expected some sort of reply, perhaps one of: - patch accepted - send your patch to xx@yy, maintainer of the tdfx driver - we don't understand and won't apply - explain why you do ... In my case the tdfx driver isn't used so much anymore, less so the XVideo support that the patch improves. Nevertheless, it seems selfish to keep the change to myself. All patch submissions to XFree86 are welcome, but the only guarantee you get when making a submission is that someone will look at it and either review it or find someone else to review it. There is no guarantee about when that will happen, but our goal is that all submissions received in time for the next release will be reviewed before that release is finalised. It's unreasonable to expect the volunteers who review submissions to do so on your timetable. Until it's reviewed, all we can tell you is that we received it and that it's in our queue (that's what the automated reply does). Once a submission is reviewed, any of the following may happen: 1. submission found to be a duplicate, or problem already fixed 2. committed with or without changes 3. submitter contacted for further information 4. held for further review 5. rejected For case 1, you probably won't hear anything back. There's an assumption that you're following the relevant area of the XFree86 development code, so you'll already know if the problem you submitted a fix for has since been fixed. For case 2, you'll see that the submission has been committed via the cvs-commit list (http://www.xfree86.org/mailman/listinfo/cvs-commit), which is archived. You can also look at the changelog extract on our web site (http://www.xfree86.org/cvs/changes.html), which is updated automatically at frequent intervals. Both your name and the number assigned to your submission should appear in the commit message and changelog entry. In cases 3 and 5 you should be contacted via email. In case 4 it depends on the further review. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Changing ctrl-alt-bckspc to ctrl-alt-delete
On Fri, Nov 01, 2002 at 09:25:30PM -0800, [EMAIL PROTECTED] wrote: David Dawes writes: On Thu, Oct 17, 2002 at 02:29:19PM -0700, Mark Vojkovich wrote: [...] It'd be nice to make this configurable, and I'm sure that a patch to do that would be welcome. There may be other ways to do this via configuring the XKB extension. But I know next to nothing about XKB. It's currently intercepting key events before they get passed up out of the DDX. I'm not sure how feasible it would be to intercept them after they've been converted into X keysyms, but that might offer a more configurable solution. XKB definately has support for defining action keys (e.g. to switch VTs or to kill the server) and the mappings are, of course, configurable. I thought I had submitted a patch long ago to enable this functionality in XFree86, but I guess I never sent it in. I'll see if I can find it in my archives. I didn't find it, so I rewrote it. This is better way of implementing than I did it before anyway. The attached patch: 1) Creates a new function to process action events that can be called both by the current code (in xf86Events.c) that intercepts special key sequences and by XKEYBOARD's action handlers. 2) Implements handling the processing of the Terminate action 3) Updates the xkb symbol maps to have a default mapping for the Ctrl-Alt-Backspace sequence to the Terminate action Thanks Joe. That looks really useful. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 4.3.0 release plans
The schedule for the 4.3.0 release is starting to take shape. The first part of that is the feature freeze. This is scheduled for 30 November 2002. The feature freeze date is last date that new features intended for the 4.3.0 release may be submitted. The address to send submissions to is [EMAIL PROTECTED] The actual release date is planned for mid-late January 2003 (before the LinuxWorld conference in New York), but the details of the rest of the schedule haven't been finalised yet. If anyone has any questions or concerns about meeting the freeze deadline, please contact me directly. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] Make xwd -frame -id work
On Thu, Nov 21, 2002 at 05:31:53PM -0500, Eric Gillespie wrote:
It has always annoyed me that xwd's -frame option does not work
when a window id is given with -id. Yes, i know that these are
separate windows with separate ids, but the id of the actual
client window is much more easily available than the window
manager frame's id (for example, easily available to fvwm
functions via $w).
Hmm, I thought that was already supposed to be fixed:
331. xwd ignores the -frame option if the -id option is used (#5251,
Mike Harris).
Did you find that to be incomplete?
David
So i changed the frame_only logic (any way we can change that
variable name? It isn't at all accurate...) instead of just
skipping the find-the-real-client-window step if -frame is given,
it will actually climb the window tree to find the wm frame.
What do you think?
Index: programs/xwd/xwd.c
===
RCS file: /cvs/xc/programs/xwd/xwd.c,v
retrieving revision 3.12
diff -a -u -r3.12 xwd.c
--- programs/xwd/xwd.c 2002/09/19 00:19:56 3.12
+++ programs/xwd/xwd.c 2002/11/21 22:19:20
@@ -203,16 +203,37 @@
target_win = Select_Window(dpy);
}
-if (target_win != None !frame_only) {
-Window root;
-int dummyi;
-unsigned int dummy;
+if (target_win != None) {
+if (frame_only) {
+Status status;
+Window root, parent;
+Window *children;
+int nchildren;
-if (XGetGeometry (dpy, target_win, root, dummyi, dummyi,
+for (;;) {
+status = XQueryTree(dpy, target_win, root, parent,
+children, nchildren);
+if (!status)
+break;
+if (children)
+XFree(children);
+
+if (!parent || parent == root)
+break;
+else
+target_win = parent;
+}
+} else {
+Window root;
+int dummyi;
+unsigned int dummy;
+
+if (XGetGeometry (dpy, target_win, root, dummyi, dummyi,
dummy, dummy, dummy, dummy)
- target_win != root) {
-target_win = XmuClientWindow (dpy, target_win);
- }
+target_win != root) {
+target_win = XmuClientWindow (dpy, target_win);
+}
+}
}
Index: programs/xwd/xwd.man
===
RCS file: /cvs/xc/programs/xwd/xwd.man,v
retrieving revision 1.9
diff -a -u -r1.9 xwd.man
--- programs/xwd/xwd.man 2002/04/22 20:53:10 1.9
+++ programs/xwd/xwd.man 2002/11/21 22:19:21
@@ -77,8 +77,7 @@
.PP
.TP 8
.B -frame
-This option indicates that the window manager frame should be included when
-manually selecting a window.
+This option indicates that the window manager frame should be included.
.PP
.TP 8
.B -root
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 ftp and anoncvs server unavailable
The system that hosts our public ftp and anoncvs servers died yesterday. There's currently no ETA for those services being restored, but hopefully they'll be available within the next week. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 ftp and anoncvs server unavailable
On Sat, Nov 23, 2002 at 12:08:41PM -0500, David Dawes wrote: The system that hosts our public ftp and anoncvs servers died yesterday. There's currently no ETA for those services being restored, but hopefully they'll be available within the next week. The public ftp and anoncvs server is back up now, and those services should be back to normal now. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [OFFTOPIC] spam scoring (was: [Xpert]*****SPAM***** Extracting a KeySym from an action routine)
On Tue, Nov 26, 2002 at 01:45:30PM -0500, Branden Robinson wrote: Hmm, so we have 3 pieces of evidence that it isn't spam, four that it is (all of which are from blacklists), the blacklist scores were enough to get the message scored as spam, and yet it wasn't spam. Are we sure we want to be investing this much trust in RBLs, at least for this mailing list? Or is there a mountain of spam that hasn't made it to the list thanks solely to the RBL rules that makes this false positive worth the trouble? I've been collecting data for the last month or so using two spam filtering tools (spamassassin and a home-grown one that we already use for our private lists). After I've analysed that data, I'm planning to use one or both of those filters to tag or drop mail sent to our public lists, and remove the subscriber-only posting restriction. As can be seen from the spamassassin-tagged messages that got through, we're not yet filtering based on that information. All I can really say so far without having analysed the data is that the number of false positives has been relatively small compared to the number of valid positives. I need to assess now many valid positives were attributable to the RBL matching before coming to any conclusions about that. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [OFFTOPIC] spam scoring (was: [Xpert]*****SPAM***** Extracting a KeySym from an action routine)
On Tue, Nov 26, 2002 at 11:26:35AM -0800, Keith Packard wrote: Around 14 o'clock on Nov 26, David Dawes wrote: All I can really say so far without having analysed the data is that the number of false positives has been relatively small compared to the number of valid positives. I need to assess now many valid positives were attributable to the RBL matching before coming to any conclusions about that. However, the false negative rate for xpert has been surprisingly high, compared to the results I've seen with spamassassin here at home. High enough to prevent me from automatically forwarding messages not tagged as spam sent by non-subscribers. When I looked at the alternatives for our private lists earlier in the year, I found that spamassassin's performance was mixed for the type of traffic our lists were getting. That's why I'm using something else there. I haven't yet evaluated how well it has peformed for the xpert list traffic. There have been several spam detector papers submitted to this years Usenix conference; I'm pretty confident that we'll have better tools available in the next couple of months. I've seen that there are different spam profiles for personal email and different types of mailing lists, and that those profiles are a constantly moving target. Those papers should be interesting. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [OFFTOPIC] spam scoring (was: [Xpert]*****SPAM***** Extracting a KeySym from an action routine)
On Tue, Nov 26, 2002 at 04:39:11PM -0500, [EMAIL PROTECTED] wrote: On Tue, Nov 26, 2002 at 11:26:35AM -0800, Keith Packard wrote: We might disable the RBL based rules in flagging spam; they do seem to have a rather high false-positive rate. Whether it's appropriate for the xpert list to partipcate in the social pressure aspect of DNSBLs (RBL is a trademark of MAPS BTW), or not, I will not comment, but just keep in mind that one of the reasons for building (some at least) DNSBLs is to exact a social pressure on the owner of the listed host[1]. I'm not particularly interested in using these lists to apply social pressure. I'm only interested in a mechanism that provides an acceptably low level of spam without imposing subscriber-only posting restrictions. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Last update to ClearlyU fonts in CVS
On Sat, Dec 14, 2002 at 12:49:12PM -0300, Davor Buvinic wrote: There is a small error in the last update to the ClearlyU fonts in CVS. Thanks, I'm committing the fix now. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]no XV on i830 anymore
On Sun, Dec 15, 2002 at 11:16:58PM +0100, Martin van Es wrote: Hi, Since a couple of days my CVS build of X (14-dec-2002) doesn't do any XV accelerated video anymore. Any work going on on this part that could be responsible for this? card: i830 (mobile). DRM/DRI/AGPGART all load and initialize without a problem. XVideo and XVideo-MotionCompensation extensions load (but never intialize?). I upgraded the kernel driver (from current kernel 2.4.20) last week when i830_drv started to complain about the old one being outdated (needed 1.3 or so dl'd and built 1.3.2 from DRI). XV still worked after this change. Then I updated my debian installation from 'stable' to 'testing', updated latest CVS and made/installed my X CVS tree. After that mplayer renders a clear blue window where before that was nice looking video :-/ No complaints/feedback about not being able to initialise XV, just a clear blue window (and a mouse pointer that suffers heavily of load!) Can you send me your X server log file? The latest i830 update includes code to turn off the video output when there isn't sufficient bandwidth for it. When that happens it looks just as you describe. It sounds like that's happening when it shouldn't. The log file should give me enough information to see why? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: improve XIM initialization performance
On Wed, Dec 18, 2002 at 04:50:23PM +0100, Lubos Lunak wrote: Hello, I hope this is the right place for this. Please review, comment and possibly apply the attached patches. With XFree4.2.x, XIM initialization takes about 66% of QApplication object initialization. This is mainly because of awful pthread mutexes performance (to express it decently), and repeated processing of the same data. The patches are done against XFree-4.2.x sources, but the affected files don't show any big changes in webcvs. All patches are for xc/lib/X11/ . The easy ones first: imLcPrs.patch - this one replaces getc() with getc_unlocked() - with LinuxThreads linked in (all KDE apps) getting rid of some locking always makes a noticeable difference :-/ . I don't think libX11 needs anywhere locked access to files, but this one is opened in a single thread in _XimCreateDefaultTree() anyway. Manpage says getc_unlocked() is POSIX.1, so I hope there's no problem with this one. It might be safest to make sure that the _unlocked version is only referenced on platforms where thread support is enabled. Maybe '#ifdef XTHREADS' is sufficient for that. lcFile.c.patch2 - the same, but this time it's gets() with gets_unlocked() - the manpages says that glibc includes it, but it's not standardized. Would it be possible to include this one together with some configure check (probably something like #ifdef __GLIBC__ )? I think LinuxThreads comes usually only with glibc. Assuming all glibc 2.x versions have it, then yes. lcFile.c.patch - during QApplication construction, _XlcLocaleDirName() is called 5 times, everytime doing exactly the same, so the patch add the obvious caching That should be OK. imLcIm.c.patch - this one is definitely not meant to be applied, it's more a proof of concept patch. The idea is similar to the lcFile.c.patch, this time it's more complicated. Every time an application starts, it loads the same Compose file and start analyzing it, generating exactly the same structure. So the patch basically takes this generated structure, packs it into one piece of memory, and stores it to a file. Next time instead of generating the structure again, it's simply mapped into memory and all pointers are corrected if the address is different. Having the whole structure cached also helps with the fact that its generation is actually done twice for some reason, once when calling XOpenIM(), once when calling XRegisterIMInstantiateCallback(). Could something like that get into the XFree cvs, and what would I have to change? I have no idea how you handle portability when it comes to stuff like mmap(), and some of you probably won't like things like fixing the pointers in the structure or mapping into memory something possibly created by a different user (the whole things almost looks like an ugly hack, doesn't it ? ;) ). I'll change this one (and the others, if needed) to meet your requirements. Since some compose files can be large, it might be useful to have a mechanism to pre-compile them. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 snapshot 4.2.99.3
XFree86 4.3.0 pre-release snapshot 4.2.99.3 was tagged a few days ago. The CVS tag is xf-4_2_99_3. Binaries for a few platforms will be available from our public ftp server: ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.2.99.3/binaries/ Currently Linux-ix86-glibc22 binaries are available. Documentation is available online at: http://www.xfree86.org/4.2.99.3/, but not all of it has been updated since 4.2.0. 4.2.99.3 has most of the features that will be present in 4.3.0. The main exception is several radeon driver updates, which will be available in a future snapshot. Please report problems here, and submit bug fixes and documentation updates to [EMAIL PROTECTED] David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HEAD compile breakage in Xserver/hw/xfree86/parser
On Wed, Jan 01, 2003 at 08:54:15AM +1100, Daniel Stone wrote: Hi all! I'm having issues with building today's CVS HEAD for Debian (I'm doing packages of HEAD, and doing it right, i.e. non-i386-specific, not a hack, etc). Specifically, programs/Xserver/hw/xfree86/parser. scan.c isn't getting built for unshared/, only ./: I don't know why anything is getting built for unshared/ in that directory. Maybe Debian patches it to build a shared copy of the parser library? This doesn't happen with the default XFree86 source. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 mailing list consolidation
Most of the public XFree86 mailing lists are being consolidated into a single list -- [EMAIL PROTECTED]. This new list is open for subscription at http://www.xfree86.org/mailman/listinfo/xfree86. Subscriptions from the old lists won't automatically be moved to the new list, so people will have to go there to join the new list. There are no subscriber-only posting restrictions, but there is automated virus/spam filtering. The four lists being migrated at this time are newbie, xpert, render, and neomagic. During a 1 week transition period, mail to these lists will be delivered to both the old and new lists. After the transition period, the old lists will be disabled, and messages sent to them will be transparently redirected to the new list. Happy New Year! David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert] Re: [dstone@kde.org: Re: [Xpert]HEAD compile breakage in Xserver/hw/xfree86/parser]
On Wed, Jan 01, 2003 at 02:31:29PM +1100, Daniel Stone wrote: Gah. - Forwarded message from Daniel Stone [EMAIL PROTECTED] - Date: Wed, 1 Jan 2003 14:17:35 +1100 From: Daniel Stone [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Xpert]HEAD compile breakage in Xserver/hw/xfree86/parser On Tue, Dec 31, 2002 at 09:54:59PM -0500, David Dawes scrawled: On Wed, Jan 01, 2003 at 08:54:15AM +1100, Daniel Stone wrote: Hi all! I'm having issues with building today's CVS HEAD for Debian (I'm doing packages of HEAD, and doing it right, i.e. non-i386-specific, not a hack, etc). Specifically, programs/Xserver/hw/xfree86/parser. scan.c isn't getting built for unshared/, only ./: I don't know why anything is getting built for unshared/ in that directory. Maybe Debian patches it to build a shared copy of the parser library? This doesn't happen with the default XFree86 source. No patches to the build system in that sense; would you like me to attach the (slightly patched) xfree86.cf and linux.cf? It'd probably be useful to see all changes relative to the standard XFree86 source. Unless there's something specifically in the parser's Imakefile to turn on building a shared version of the library, or something in the .cf/.tmpl/.rules files to always build shared libraries, then I don't see why it would even be trying to do what you're seeing. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
