Re: [Xpert]Re: Replacing X with a KDrive (P.R. Patil)
You can run Gnome/KDE with kdrive just fine. The biggest headache is getting kdrive all its command line arguments, in particular, the font path; this makes for a long command line for the X server. Kdrive does not use a configuration file (which may not exist in embedded applications). The one problem I remember wasa limit in the X server on the size of the server's argument list, that was only enforced if you weren't root, that we ran into. I think we upped the limit, but don't remember precisely. Keith, do you remember? - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Kdrive: host.def examples and suid issue?
Attached is the host.def I use to build kdrive for the iPAQ handheld, and when running the kdrive server on my laptop. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] host.def Description: Binary data tinyxhost.def Description: Binary data
Re: [Xpert]FW: Lots of IP traffic, no screen activity
X is very sensitive to latency as well; we designed X for high speed (of the day) campus scale networks. ISDN and dial up lines therefore suffer both due to limited bandwidth and large latency, not a good situation. Running Xft based applications (e.g. Gnome 2 with Xft and KDE 2.2 or later with AA fonts turned on), may perform better, as one of the killers is round trips for font discovery, which Xft/fontconfig makes a thing of the past. Keith and I are working on getting some more recent data of what is actually going on on the wire with the render protocol changes for Usenix next summer (just got our first data today, as a matter of fact). Mozilla/Netscape is a prime offender, enumerating just about all fonts and retrieving metrics for them all; again, if you get the most recent Mozilla beta test built with Xft support, this should be avoided. - Jim Gettys -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]FW: Lots of IP traffic, no screen activity
- On Tue, Nov 12, 2002 at 11:00:44AM -0800, [EMAIL PROTECTED] wrote: Running Xft based applications (e.g. Gnome 2 with Xft and KDE 2.2 or later with AA fonts turned on), may perform better Any way to get this benefit without actually enabling anti-aliasing? While I'm generally pleased with my forwarded X11 displays, some apps are still murder. I'd dig trying this, but I don't particularly like the look of AA fonts. Rebuild your freetype to have hinting turned on (it is usually off by default) and install good fonts (e.g. the MS web fonts) and you'll really like AA fonts :-). - Jim ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]FW: Lots of IP traffic, no screen activity - WOW! Exp erts in deed.
RH 8 has much of the right stuff, but not all. I don't think they shipped a Mozilla with Xft support, though I might be wrong. There is a set of RH8 Moz rpm's up in the experimental area of the mozilla.org web site with Xft/Fontconfig support of the latest beta test: I recommend those. One of the amazingly stupid things event that moz does right now is walk the X server tree on startup to see if there is another moz already running (this is stunningly obvious in the packet traces Keith and I were staring at this afternoon). Not so bad on a high speed link, but god forbid if you are on a high latency line. This needs to be fixed (in moz). After that initialization, moz looked pretty good on the wire: almost all traffic is outbound to the X server once the tree has been walked. It was very gratifying to me personally to see moz run alot faster once we turned on HTTP/1.1 pipelining. People should try that as well, though there are some broken proxies out there. Hopefully in the next few days we'll have alot of other insights (we stared at our first traces today). Keith also thinks GetImage in the X server is far from right. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... It is mostly someone who has time to bother to get it all done - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
I've just chatted with Keith Packard on this. This interface (an ioctl that blocks) isn't a good one. How about a signal when vertical blanking arrives? (1st choice) That, or something we can select on? (2nd choice) - Jim Gettys Sender: [EMAIL PROTECTED] From: Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] Date: 01 Nov 2002 22:01:46 +0100 To: [EMAIL PROTECTED] Subject: Re: [Xpert]But *why* no vblank? - On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
As Keith says, we (in this case, not Keith, but my co-authors and myself) designed XSync with the network in mind, and to avoid both network and process scheduling latencies. The model is that you can have a whole set of requests queued (and transmitted to the server), blocked on a counter (the basic abstraction). Basically, a request says: block this connection until the counter gets to a specified value. Docs are in the tree So when the counter (in this case, a vblank counter) increments, the X server gets woken up, the X schedular sees that there was a client blocked on that counter, and it can immediately execute (one or more) request(s), already present in the input buffer of the X server. You can also get informed the counter incremented by an event, but that is slow: the event mechanism is mostly to (as in TCP) serve as a clocking mechanism, so your application can know to get the next (set) of requests to the X server for the next counter increment. In this way, we can avoid network round trip times (and multi-process scheduling latencies) and achieve very fine synchronization, either between X clients or with external events (real time, or vertical sync). All this was fully tested/debugged in the early '90's, when the UNIX desktop died; it has been the lack of driver support that has held this back. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Question about X protocol
There are many clients, one server. Particularly in the days before shared libraries, this meant that by doing most byte swapping in the server, we ended up using less memory over all. And we anticipated there being multiple implementations of X protocol libraries: this has been less common than we expected, though there is now a very interesting X library under development by Bart Massey and a student. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] From: Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] Date: Thu, 24 Oct 2002 16:46:14 +0700 To: [EMAIL PROTECTED] Subject: [Xpert]Question about X protocol - Hi! As I understand, when an X server deals with clients having different byte order, it is the server who does LSB-MSB conversion, not the client. Is there any documentation which lists the reasons of that decision? (Yes, I understand that this question probably belongs to a general X list, but xpert list seems to be currently the most authoritative.) TIA, Dmitry _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XML format for XF86Config
It has to be editable for those who still use a config file (custom settings, modelines, etc) and personally I think the current format is quite nice for hand-editing. What I've seen of XML doesn't have that quality. For better, or for worse, XML looks like HTML, and many/most system managers have the ability to deal with it; I for one find XF86Config files as inscrutable as any XML I've seen. And XML can be validated and edited mechanically, two major features. This being said, I'd like most of the effort to go toward making the file unnecessary entirely; if something has to remain, then maybe it would make sense to use XML for it. But let's work on making it obsolete, now that the hardware is much less insane than it once was. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Resize and Rotate extension progress report (options)
I'd like to bring this back toward reality a bit, though I'm happy to see the interest, and do not wish to discourage that discussion. The rest of RandR have been done, for kdrive, and immediate integration into the mainline XFree86 server is managable. So we have 3 options: 1) Integrate what we have, as is. Features: Least work for us. If we happened to get the design right for depth switching, the protocol framework is there. Bugs: The depth switching part of the protocol is untested, which means it may have lurking problems we would not discover. 2) Strip out depth switching, and integrate into the XFree86 mainline server. Depth switching can be added later, as additional interfaces. Features: We can rely on this part of functionality to not change, and remains stable. Bugs: We hope, none :-). Some more work to strip out the depth switching part of the protocol and library; this is a day or so's work. 3) attempt to do the depth switching immediately. Features: we get the entire cake, someday, maybe. Bugs: 4.3 is almost upon us, and there is no way to get depth switching done in time that we can see, even if there were magically more resources expended to work on it immediately. I think the realistic result will be nothing happens. I don't think 3) is really an option: we don't have time even if we had resources. I'm very nervous integrating and deploying functionality that hasn't been fully tested; but as someone who has a laptop, I really want size changing, and I suspect many other people do as well. The history, both in X and other protocols, is that there are almost always problems not discovered until implemented for real. The compromise is that there are configurations that will fit into VRAM than we cannot provide without depth switching. So, given today's date, and that 2) does not preclude future implementation of depth switching, I think we should pull out depth switching in the RandR protocol and get what we have finished, integrated, and fully deployed. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
I've let this discussion go on a few days. So far, Andrew is the only one to actually say he's at all interested in seeing completion of RandR's depth switching. Given that modern toolkits either have, or could have the fundamental capability that is wanted, I suspect the work is better put elsewhere. And I note that the functionality he and I want (the ability to, for example, migrate from PDA to living room wall) also will generally require apps that can reload UI's (e.g. glade based, in the GTK world) to actually be interestingly usable across such different screen sizes. Certainly the emergence of this capability in (a) modern toolkit has seriously reduced my own motivation to drive this to completion, and Keith has had some misgivings about this possibly constraining other work that needs to go on inside the X server. Similiar migration work is not likely to occur with Xt/Motif/Xaw apps without someone seriously interested in driving Xt/Motif/Xaw forward, something I've not been able to detect, whereas both GTK and Qt have serious communities driving them further constantly (and functionality one has generally appears in the other in finite time). I'll see if it is practical to do the library interface in such a way that if depth switching were implemented someday, it would not break interfaces. Much of the interface is pretty opaque, already, and not fully exposing the visual group and groups of groups semantics. So unless people crawl out of the woodwork to say I'm wrong, I plan to remove/hide the depth switching part of RandR so that we can go mainline with what we have running today, without exposing us to the danger parts of the design were broken due to lack of implementation experience. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Resize and Rotate extension progress report
Out of curiosity, is the difficulty in switching depths or visual types? It might be useful, for example, to switch applications between a 16-bit TrueColor visual on a laptop with a limited amount of video memory and a 32-bit TrueColor visual on a nearby desktop. This seems like it would be far less complicated than emulating PseudoColor. Rendering to different depths is a bit tricky, though doable (or we wouldn't have done the design work). Pseudocolor writable colormaps are a serious pain. But by the time it was implemented and deployed, your laptop will likely no longer have this memory limit. I had this argument with Keith; and I think his claim Moore's law is making this moot pretty fast is probably correct. So it might be still worth doing if someone *really* wants to do it, and do it quickly, but so far, we've not identified such a person with that interest and ability. Barring that person, (which isn't me, given the recent developments in modern toolkits, and the applications I use), it seems safest to deploy what we *know* works correctly and is useful to everyone sooner than hoping it happens someday, and have the functionality never be standard. And all my instincts and experience are to avoid making standard anything that isn't *fully* tested. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
I will note that even almost all Xt/Motif apps will deal with non-pseudocolor default visuals, since 8 bit frame buffers have mercifully been rare for a long while now: our going in strategy had always been to make pseudocolor not the default visual, so that few apps would be using pseudo-color as their default visual in the first place. As Keith says, it is the depth switching part we worry about most, and looks the most complicated in the current server infrastructure. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
http://zap.crl.dec.com/randr.pdf http://zap.crl.dec.com/randr.ps http://zap.crl.dec.com/randr/randr.html Have the Usenix paper (which should be available on the Usenix web site, but for some reason, it isn't: I've complained at them to fix this). - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X process redirection...
Fabrizio, Current GTK 2 CVS has code for screen migration (even between X servers) A person at Sun (whose name I always forget) did the screen migration stuff this spring, I then tested it worked even between servers, and Owen Taylor has since done some work to try to shake out more of the resulting problems. So making GTK/gnome apps migrate is within reach. There are security implications to this, of course, which need work. Also, emacs has had migration capability for a decade. Unfortunately, naive Xlib/Xt apps are unlikely to be retrofit this way; it requires some thought when you design a toolkit, something that has been sadly lacking. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TinyX documentation?
Sender: [EMAIL PROTECTED] From: Rich Cyr [EMAIL PROTECTED] Date: Wed, 24 Jul 2002 10:15:07 -0400 To: [EMAIL PROTECTED] Subject: [Xpert]TinyX documentation? - Hello, Is there any documentation that describes how to build and install the TinyX (kdrive) servers from source code? http://www.handhelds.org/minihowto/building-x.html This specifically talks about how to cross build, but native is just about the same, if you ignore the obvious things... This instant, the iPAQ touchscreen support seems to be broken; I'm looking into this as I write this. - jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
Mostly works on my laptop: Compaq Evo N600c, using Radeon Mobility M6 LY (rev 0), under Linux RH 7.2, running a 2.4.18 kernel. I note two problems (both existing before this patch, so this is old news): o If I switch to a different VT, after a few seconds, the machine hard hangs. o When logging out from Gnome, the logout dialog screen is funny, with two vertical black bars from the edge of the dialog box. I've not tried playing with DRI (which is disabled in my XF86Config-4 file. - Jim Sender: [EMAIL PROTECTED] From: Kevin E Martin [EMAIL PROTECTED] Date: Thu, 11 Jul 2002 16:27:40 -0400 To: [EMAIL PROTECTED] Subject: [Xpert]ATI Radeon patch testing - I've just checked in a large patch from ATI. Here's the CHANGELOG entry: 199. ATI patch to: - Fix Dell OEM VE card support - Add better clone mode support - Fix large panel (= 1600x1200) detection and initialization problems - Remove PanelSize and CrtScreen options since they are no longer needed with new CloneMode and improved flat panel support - Add DDCMode option to detect and use DDC modes - Add PanelOff option to disable panel on laptops - Fix corrupted console problem - Other misc fixes (#A.1043, Hui Yu@ATI). I'd like get some feedback on how it works for others with both desktop and laptop Radeons. I'll start working on the other patches that have been sent in shortly. Thanks, Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Appearance in X...
Freetype's byte-code hinter may not be turned on on your system, depending on what distribution you run. Without it enabled, your font rendering will look significantly worse than on Windows: with them, it should be entirely comparable. Also note that the XftConfig file as shipped by some vendors is badly broken, so you may not get the behavior you'd like either due to that. - Jim Sender: [EMAIL PROTECTED] From: Xpert [EMAIL PROTECTED] Date: Fri, 7 Jun 2002 18:41:06 +1000 To: Xpert mailing list [EMAIL PROTECTED] Subject: [Xpert]Appearance in X... - Can anyone shed any light on why KDE looks so bad compared to Windows? The KDE fonts are really rough and difficult to read, particularly when they are small. I don't know that it is just just the lack of True Type fonts (although this is probably a contributing factor) as I have installed a whole bunch of Windows TTFs and it has made little difference. I have tried using True Type fonts and have checked the Anti-Aliasing for Fonts box in the KDE Control Centre, but they are still quite fuzzy compared to those in Windows. I am trying to get Red Hat 7.3 installed at my work to replace our network of aging Win95 PCs, but I just _know_ that as soon as the staff see the terrible fonts that they will reject it out of hand. I am evaluating Galeon, OpenOffice 1.0 and Evolution as that is all most of our office will need, but the appearance compared to IE, MS Office and Outlook is terrible. Can anyone offer any information/advice/website that will help me to get them a Windows-quality display? Regards, Brad Brisbane, Australia ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Reg. X Security Extensions
Since projector prices are dropping, a projector is now not much more than a hacker's hacker machine (2-3K), so projectors are becoming much more common, and are appearing in many/most conference rooms, and they all sport VGA connectors... Keith and I have been spending some time thinking about projector walls, that would incorporate multiple displays, and give higher resolution, but we've not done anything real yet. - Jim Sender: [EMAIL PROTECTED] From: Juliusz Chroboczek [EMAIL PROTECTED] Date: 04 Jun 2002 15:47:43 +0100 To: [EMAIL PROTECTED] Subject: Re: [Xpert]Reg. X Security Extensions - I've never seen anybody use the security extension, and have yet to feel the need for it. AA It seems to appear at the same time as the remote X extension, xrx, AA which makes me think that the idea something like this: AA You have a browser (netscape was one possiblility) with an xrx AA plugin, and browse my web site. Yep, that's what the XC claimed when X11R6.3 came out. Remarkably dumb idea. Shows a complete lack of understanding of what type of problems Java and the technologies based on Javascript and CSS (``dynamic HTML'') are trying to solve. (A wide-area round-trip for every expose event andevery keystroke. Sheesh.) Jim's example is more convincing, though. Are there any video projectors that embed an X server? Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Reg. X Security Extensions
I've never seen anybody use the security extension, and have yet to feel the need for it. The scenario I see where it may have use is for shared environments like projectors/projector walls, so you might have much looser access control than usual, but want some level of projection between users. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XftConfig with Kdrive server?
Sender: [EMAIL PROTECTED] From: Alex Pavloff [EMAIL PROTECTED] Date: Wed, 29 May 2002 11:00:43 -0700 To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: [Xpert]XftConfig with Kdrive server? - The KDrive servers ignore the XF86Config files, but do they ignore the XftConfig file? It seems like my dir entries aren't used, and I have to explicitly specify the font paths to my truetype and type1 fonts on the command line. All help appreciated. XftConfig is for client side fonts using the render extension, using Xft1. Planned, but not yet implemented, is to update the font library the server uses (for either kdrive or XFree86 servers) to get its default font path for legacy core X11 fonts from the new FontConfig library (which was part of Xft1, and has been separated into its own library since many non-X projects have needed similar facilities). So yes, right now, you have to configure both separately, which is a pain. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Troubles in cross compile land...
Egbert, I tried using the new cross compile system. I'm having all sorts of problems For example, it seems to be including the host header files rather than the X header files in the development trees Keith and I have both looked at it, and are scratching our heads There are two ways for you to look into this: I could give you an account on my laptop, and you could poke at the build, or you can install the cross compile toolchain we use for the iPAQ, and reproduce it yourself. A description of how to get and install the cross chain we use, and how X used to be build using it can be found at: http://www.handhelds.org/z/wiki/Notes%20on%20Developing%20using%20Cross%20Compiler So, I guess Keith and I are yelling: Help! - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Where Should I Be Sending Patches?
There are four ingredients for a bug tracking system to succeed, as I see it: 1. Interest and cooperation from the developer community itself 2. The machine resources/network to support the system (available; I know we have a machine here we could use, if no other, so it is a certainty) 3. Good installation and customization of the system to provide good catagorization of bugs (two people have volunteered with this part of the problem, Kurt Wall, and Jeff Waugh (via private mail to me)) 4. Someone (or set of people) to perform bug triage, entering existing bugs initially, and once established, assign initial catagories, mark duplicates, produce statistics as releases near, and eventually cull the database of long fixed bugs. 1) is obviously essential. And 4) is needed to keep the quality up, so that the developers don't go nuts (for example, what happened to the nautilus folks during Gnome 2 development). Many of the major projects have serious resources assigned to the triage/catagorization and maintenance of their bug tracking systems. So 4) is also key (2, and 3 can be considered solved problems, IMHO). 3) is a significant amount of work initially, and only a small amount ongoing: if things aren't set up well (and tuned), then bug reports are hard to deal with and don't go in the right directions. I gather some previous attempts were not well done. I know that Jamey Hicks here spent a number of days working out this catagorization stuff on the handhelds.org bugzilla, so this is not just a one day and your done sort of job. As Mike points out, establishing a transparent system would allow more people to actually help on resolving problems. It is also a way for people to get their feet wet on the project (as they do on some of the other major projects) by taking bugs, working on fixes, and posting patches. Some people even appear to enjoy this sort of work. With the current opaque system, there is no way to enlist people into helping with bug fixing. Some of the most valuable people in some other projects wander around fixing lots, and lots, and lots of bugs. This would help the scaling issue, I think, which XFree86 faces. So the outstanding questions are: 1) are the people who do XFree86 developement interested/willing to work with such a tool? 2) who is willing, if anyone, to become bugmeister and properly deal with the database? This is a significant amount of work; one might argue that the commercial Linux vendors are those with the most to gain by helping out here. I think answers to both in the affirmative are necessary before one goes any further, and unless the answers our yes, we live with the current system until there are credible answers. If this is done, it had better be done well: I gather that previous attempts have failed for various reasons, and I think good answers to all four questions are essential. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Touchscreen on Compaq iPAQ H3600
Sender: [EMAIL PROTECTED] From: Klaus Reimer [EMAIL PROTECTED] Date: Fri, 10 May 2002 20:16:16 +0200 To: [EMAIL PROTECTED] Subject: [Xpert]Problems with Touchscreen on Compaq iPAQ H3600 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a problem with the current version of Xfree86 (4.2) running on an Compaq iPAQ H3600 handheld. I downloaded the current Xfree86 4.2 source code and configured it for cross-compiling the KDrive/Xfbdev server. Compilation works without any problems. The problem is, that the touchscreen is not working. I investigated this issue a little bit and I don't understand it: On initializiation the function KdMouseInfoAdd() is called. After this point the touchscreen is definitely working. But then the function MouseInit() calls the function KdMouseInfoDispose() and after this point the touchscreen is no longer working. I don't know the internals of Xfree86 so I don't know why the mouse (touchscreen) is first initialized and then disposed. If I disable the call to KdMouseInfoDispose() the touchscreen is working but Xfree86 segfaults on shutdown. What is the correct way to get the touchscreen working? Who can help me on this issue or can point me to helpfull informations? If this is the wrong list for such a question, please point me to the right one. I don't know off hand: the last X server I built and fully tested for the iPAQ was last August or September, before I went out for surgery. I'm setting up to be able to build again now, but haven't yet, so it is conceivable that there is a bug that has been introduced. There are a number of possibilities: the kernel header files in your cross build environment might be stale, there might be some probelm in your configuration file, or some latent bug in XFree86. So you should at least provide: 1) what toolchain you are using (I recommend using the CRL cross toolchain; it is the only one I've used). 2) whether or not you updated your kernel header files in the the cross environment. 3) your xc/config/cf/host.def file 4) what kernel you are running on your iPAQ (I recommend the current 2.4.18 version). Thanks, - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Touchscreen on Compaq iPAQ H3600
I'd suggest as a first thing to try to build the kernel from the handhelds.org CVS. Running just with RMK patches will often miss things. We feed things upstream to Russel King, but sometimes things aren't in a consistent state and there has been a lot of work in the fbdev area in recent memory. So that area has been in a state of flux, and the only guarantee of consistency is in our CVS. -Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Touchscreen on Compaq iPAQ H3600
I'll see if I can reproduce it tomorrow (Tuesday). - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
