fspanel || learning XLib and Xinerama
I've just discovered fspanel. I love it because it it so so simple. I use XFree86 on MacOSX so my OS is already provided for me and I don't need all the "extra" features of gnome or kde just to get their panel. Here's my issue: fspanel doesn't have the vaguest idea about Xinerama, and I have multiple displays. This makes it impossible to make it show up on the correct one correctly. ;-) First, if anyone has a patch/hack/whatever that will make it work, pls tell me!? or even a similarly lightweight panel. I've looked at fbpanel and hpanel, they aren't what I'm looking for, and I'm not entirely sure they support Xinerama either. Second, failing my first request: Could someone point me in the right direction to learn Xlib and Xinerama myself? I know some C (I understand the language, but have very little experience) and I'd like to be able to fix this myself. :-) Help is appreciated, JP It's all fun and games 'til someone writes to a NULL pointer! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xf86AddInputHandler
hi, I have spent some time recently to dive into XFree86 source code: I am looking into learning more how it works to understand better X performance in my application. One of the things I don't really get is what xf86AddInputHandler is supposed to be used for. Despite reading a lot of code and grepping multiple times, I found only very few locations using xf86AddInputHandler and I could not figure out what it is used for. I'd be most grateful for any kind of hint :) Mathieu -- Mathieu Lacage <[EMAIL PROTECTED]> ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
Hi; on Tue, Jul 29, 2003 at 11:04:35AM -0700, Tim Roberts wrote: > The IMAGEON 100 will never be a stellar performer. It was designed for low > cost and low power, not high performance. It does have a simple blitter, and > it has a reasonable YUV overlay, but the motion compensation acceleration is > only slightly better than straight software. > I dont think were expecting 'stellar' performance here, just reasonable will do - the current situation is ~700 k/sec bandwidth in certain xrandr orientations. > There is an O/S-independent (theoretically) acceleration layer for the > IMAGEONs, but it is ATI-proprietary, and to my knowledge is only released to > their partners. > I think parts of this are exposed in the w100 framebuffer driver ( in the sharp kernels source ), though its pretty much undocumented and I dont really wanna risk boiling a 400$ lcd poking it. > >So please if anyone from ATI is listening, please consider to support an > >XFree86 driver development! > > Didn't we just see this movie? What's their incentive to do so? The people > who are selling IMAGEON-based devices want Windows CE, and ATI is happy to > help those people with CE drivers. > ATI do mention on there Imageon page they support 'Linux mobile'. Just wondering where/what that is Also, I think this is a different movie. The embbeded market is different to the desktop one. Many thanks; -- Matthew Allum ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
Matthew Allum wrote: Hi; [ snip ] ATI do mention on there Imageon page they support 'Linux mobile'. Just wondering where/what that is Also, I think this is a different movie. The embbeded market is different to the desktop one. Hmm, have you tried asking trolltech? After all, they did do the QT GUI for the Zaurus and presumably would need to know how to access the framebuffer, this being embedded. So one would assume that _some_ docs must have been available ... Cheers, Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux AG S390 & zSeries Deutschherrnstr. 15-19 +49 911 74053 688 90429 Nürnberg http://www.suse.de ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
You will love it
Title: ad As Seen On TV: CNN, ABC News And More ... Doctors Create VPRX Penis Enlargement Pills Gain Up To 3+ Full Inches In Length Increase Your Penis Width (Girth) By 20% Stop Premature Ejaculation! Produce Larger, Rock Hard Erections 100% Safe To Take, With No Side Effects Fast Priority Fed-Ex Shipping WorldWide Doctor Approved And Recommended No Exercises! No Pumps! No Surgery! 100% Money Back Guarantee FREE Bottle Of VP-RX Worth Over $50 FREE "Male Help E-Book" Worth Over $50 >CLICK HERE TO READ MORE No Thank you, I want Out
COMPOUND_TEXT handling of iso8859-15
Bugzilla #228 claims that the handling of iso8859-15 in COMPOUND_TEXT is incorrect. According to the ctext documentation no extended segments should be used for any approved standard encoding. According to the newer revision of this doc (xc/doc/specs/CTEXT/ctext.tbl.ms) is8859-15 is such an approved standard encoding. However XFree86 contains code to grant backward compatibility to XFree86 3.x that uses extended encodings for this. How importand is the backward compatibility to versions of Xlib for 3.x? Should we remove this code which makes our COMPOUND_TEXT handling violate the specs? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Think about it. Once you do the above, anytime you checkout the repository at any point in the past, suddenly it has changed from all former archives of the past. -- Todd Fries .. [EMAIL PROTECTED] Free Daemon Consulting, LLCLand: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 06:14:06AM -0500, Todd T. Fries wrote: > Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: > [..] > | I did suggest this (mv hp,v hp.old,v). > > If you guys care about history at all, aka the ability to checkout files > in the past, you would not suggest nor impement this suggestion. If anyone cared about it, they wouldn't still be using CVS, probably. :P Sadly Subversion is still a little too buggy (the whole server-and-client-must-have-matching-versions thing) and arch a little too non-existant to have a real replacement, especially when you consider that cvs2svn and the ilk are ... ugh. > Think about it. Once you do the above, anytime you checkout the repository > at any point in the past, suddenly it has changed from all former archives > of the past. Yes, but what's the alternate solution? I really don't like the changed-case solution, as that sets a precedent of sorts. A note should be made somewhere of the moved files. KDE moves files around all the time. It's all you can do to work around the limitations of a fundamentally crippled system. Think of CVS as i386, and SVN as PowerPC (no, I'm not a Machead - I run i386 machines at home, and only have a PowerPC at work because I didn't have to pay for it, but I admire its architecture). -- Daniel Stone <[EMAIL PROTECTED]> http://www.kde.org - http://www.debian.org - http://www.xwin.org "Configurability is always the best choice when it's pretty simple to implement" -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
Re: CVS Update: xc (branch: trunk)
There is, as you say, no current usable option. I'm personally using OpenCM (http://opencm.org). In the future it will be much more viable than it is now. Then it would be a very usable option. The unuse-ability at this point is slowness, reliance on boehm-gc, and no sub-projects (implemented) yet. Aka you cannot just checkout a subdir, it is the whole project or not. There are promises to implement this as well. The reason I am using it is its integrity (sha1 throughout) and security (openssl connection to the repository, uses ssl certificates (not signed) as user keys to the repository) and has first class branch support. It makes it very easy to track my own private development `branches' for my uses in OpenBSD when trying out bind, vinum, v6 apache, SMP, v6 X, and several others. But it is very much slow going when doing a checkout or a commit on anything but relatively small projects. Hence, it is not ready for consideration *yet*. Thanks, -- Todd Fries .. [EMAIL PROTECTED] Free Daemon Consulting, LLCLand: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) Penned by Daniel Stone on Wed, Jul 30, 2003 at 09:28:10PM +1000, we have: | On Wed, Jul 30, 2003 at 06:14:06AM -0500, Todd T. Fries wrote: | > Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: | > [..] | > | I did suggest this (mv hp,v hp.old,v). | > | > If you guys care about history at all, aka the ability to checkout files | > in the past, you would not suggest nor impement this suggestion. | | If anyone cared about it, they wouldn't still be using CVS, probably. :P | | Sadly Subversion is still a little too buggy (the whole | server-and-client-must-have-matching-versions thing) and arch a little too | non-existant to have a real replacement, especially when you consider that | cvs2svn and the ilk are ... ugh. | | > Think about it. Once you do the above, anytime you checkout the repository | > at any point in the past, suddenly it has changed from all former archives | > of the past. | | Yes, but what's the alternate solution? I really don't like the changed-case | solution, as that sets a precedent of sorts. A note should be made somewhere of | the moved files. | | KDE moves files around all the time. It's all you can do to work around the | limitations of a fundamentally crippled system. | | Think of CVS as i386, and SVN as PowerPC (no, I'm not a Machead - I run i386 | machines at home, and only have a PowerPC at work because I didn't have to pay | for it, but I admire its architecture). | | -- | Daniel Stone <[EMAIL PROTECTED]> | http://www.kde.org - http://www.debian.org - http://www.xwin.org | "Configurability is always the best choice when it's pretty simple to implement" | -- Havoc Pennington, gnome-list ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: arc rasterization
Hi Craig, Here is some bibliography in the field of curve rasterization: http://le-hacker.org/hacks/drafts/curve/ I also did put together some papers on automatic layout: http://le-hacker.org/hacks/pagination/ Mathieu Le mar 29/07/2003 à 18:00, Craig Groeschel a écrit : > I am hoping someone can help out with citations. > > Long ago, there were some arc xtests which always failed. I > remember reading/hearing that some folks at Digital proved that > 128-bit math was required for these tests to pass. Then I > recall hearing that the code had been fixed and all the arc > tests now pass. > > I'd appreciate it if anyone could point me to any published > papers, articles, mail messages, source code, or rendering > specs. > > > I am also casting about for research topics and would > appreciate any suggestions, especially in the area of high > performance numerical algorithms e.g. rasterization, rendering, > raytracing, radiosity. Are there any open problems in glyph > rasterization, or is that all so eighties and nineties and > called Metafont, PostScript, etc.? > > Thank you for reading. > > = -- Mathieu Lacage <[EMAIL PROTECTED]> ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, 30 Jul 2003, Daniel Stone wrote: > On Wed, Jul 30, 2003 at 06:14:06AM -0500, Todd T. Fries wrote: > > Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: > > [..] > > | I did suggest this (mv hp,v hp.old,v). > > > > If you guys care about history at all, aka the ability to checkout files > > in the past, you would not suggest nor impement this suggestion. > > If anyone cared about it, they wouldn't still be using CVS, probably. :P it's not a problem unique to CVS. > Yes, but what's the alternate solution? I really don't like the changed-case > solution, as that sets a precedent of sorts. A note should be made somewhere of > the moved files. one alternative is to copy the ,v file to the new name (if all you're concerned about is finding the "real" history for a particular file). But simply renaming the file is a bad practice - bites everyone else, whether or not it affects the person who moved the file. -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Can we get back on topic here? The long and the short of it is that I cannot checkout the xf-4_3_0_1 tag until someone moves hp out of the way. I can delete hp and do a cvs update, but it [obviously, if you think about it] pulls down hp again before trying to get HP. I know this can be fixed, because I can checkout HEAD, but could someone give a little TLC to xf-4_3_0_1 (and xf-4_3-branch) to make sure that whatever was done to make HEAD work is done to make those tags work again? Thanks in advance, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, 30 Jul 2003, Harold L Hunt II wrote: > Todd T. Fries wrote: > > > Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: > > [..] > > | I did suggest this (mv hp,v hp.old,v). > > > > If you guys care about history at all, aka the ability to checkout files > > in the past, you would not suggest nor impement this suggestion. > > > > Does history matter when some people simply cannot checkout a tag set > because of a mistake that was made? The balanced response here is that > the history is not as important as making sure that all developers can > move forward. Of course, we do this only in rare circumstances, but > this is one of them. I fetch older versions all the time - on xfree86, I did that, for instance to narrow down the range of dates for a bug introduced into the mouse driver. Having a known working version of something lets you cut down on the effort to isolate a bug. (Moving "forward" doesn't use the archives for anything except an odd backup format). -- T.E.Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Daniel Stone writes: > On Wed, Jul 30, 2003 at 07:38:30AM +0200, Alexander Pohoyda wrote: > > > Egbert Eich wrote: > > > > CVSROOT: /home/x-cvs > > > > Module name: xc > > > > Changes by:[EMAIL PROTECTED] 03/06/20 06:15:33 > > > > Log message: > > > > - moving xkbcom/geometry/HP to xkbcom/geometry/hp doesn't seem to be > > > > possible as CVS doesn't allow a directory to have the same name as > > > > a deleted file. > > > > Added files: > > > > xc/programs/xkbcomp/geometry/HP/: > > > > Imakefile hp omnibook > > > > I have developed the omnibook geometry and I have a new geometry for > > the DELL Inspiron laptop. I'm not submitting the latter because I > > would not like to see a new directory DELL there. > > Why should some company names be capitalized and others not? > > Uhm, HP is an abbreviation for Hewlett-Packard - two proper nouns, which should > be capitalized. Dell, on the other hand, is just the last name of Michael, and > thus shouldn't be fully capitalized. All names should be lowercase. HP is upper case because there was a file hp in this directory before. CVS doesn't allow you to create a directory with the same name as a previously deleted file. The reason seems to be that in CVS directories have no version number. > > > Would it be possible to fix this issue on the repository side? I mean > > manually delete files `hp' and `dell' and create directories instead? > > I did suggest this (mv hp,v hp.old,v). > You can move the file hp,v to hp.old,v I suppose. Unfortunately when you check out an older version it will not build because it does not find the file hp. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Thomas E. Dickey wrote: On Wed, 30 Jul 2003, Harold L Hunt II wrote: Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. I fetch older versions all the time - on xfree86, I did that, for instance to narrow down the range of dates for a bug introduced into the mouse driver. Having a known working version of something lets you cut down on the effort to isolate a bug. (Moving "forward" doesn't use the archives for anything except an odd backup format). What's the problem here? Go look at HEAD! HEAD checks out just fine and has already had the "hp" file moved out of the way. Your argument is moot. The only problem is that the decision that was made and applied to HEAD has not been applied to xf-4_3-branch. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, My main question here is why does HEAD not have "hp" while xf-4_3-branch still does? I can checkout HEAD, but I cannot check out xf-4_3-branch because "hp" is in the way. Do the changes that you applied to HEAD need to be applied to xf-4_3-branch as well? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86AddInputHandler
Mathieu Lacage writes: > hi, > > I have spent some time recently to dive into XFree86 source code: I am > looking into learning more how it works to understand better X > performance in my application. > > One of the things I don't really get is what xf86AddInputHandler is > supposed to be used for. Despite reading a lot of code and grepping > multiple times, I found only very few locations using > xf86AddInputHandler and I could not figure out what it is used for. I'd > be most grateful for any kind of hint :) > Please take a look at: http://xfree86.linuxwiki.org/xf86_2a_2a_20Functions Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Daniel Stone writes: > > Yes, but what's the alternate solution? I really don't like the changed-case > solution, as that sets a precedent of sorts. A note should be made somewhere of > the moved files. One could name it hewlett-packard if lowercase is importand. > > KDE moves files around all the time. It's all you can do to work around the > limitations of a fundamentally crippled system. > Yes, but we don't. Due to the reason given above. The uppercase/lowercase issue doesn't justify breaking builds of checkouts of older versions. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
Hi on Wed, Jul 30, 2003 at 12:04:26PM +0200, Hannes Reinecke wrote: > > > Hmm, have you tried asking trolltech? > After all, they did do the QT GUI for the Zaurus and presumably would > need to know how to access the framebuffer, this being embedded. So one > would assume that _some_ docs must have been available ... >From what I could tell judging by how it performed on the C700, qt is just writing strait to the framebuffer device as well ( which there is cryptic source for ). I suspect and would hope this has changed in the newer C7xx's ( which afaik still have Imageons ). Also considering kdrive essentially is a competitor to qte Im not sure how helpful they'd be... Many thanks; -- Matthew ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
On Wed, 30 Jul 2003 10:43:42 +0100, Matthew Allum wrote: > >on Tue, Jul 29, 2003 at 11:04:35AM -0700, Tim Roberts wrote: > >> Didn't we just see this movie? What's their incentive to do so? The people >> who are selling IMAGEON-based devices want Windows CE, and ATI is happy to >> help those people with CE drivers. > >Also, I think this is a different movie. The embbeded market is >different to the desktop one. Yes, but if anything, the situation is even worse in the embedded market. In the general computing world, the vendor has to worry about both OEM sales and retail sales. In the embedded world, you ONLY have OEM sales. You cannot go out and buy an Imageon 100 add-in card for your Zaurus, so there is even less incentive for the chip vendor to provide any public support. Their consumer is the OEM. If the OEM is happy, ATI is happy. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Harold L Hunt II writes: > Egbert, > > My main question here is why does HEAD not have "hp" while xf-4_3-branch > still does? I can checkout HEAD, but I cannot check out xf-4_3-branch > because "hp" is in the way. > > Do the changes that you applied to HEAD need to be applied to > xf-4_3-branch as well? > Hm, I don't really understand the reason why you have this problem. It must have to do with the fact that in order to get to this branch in cvs you have to apply all the patches that were along the way. Looking at the messages that CVS writes this seems to be the case: ... U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs checkout: Updating xc/programs/xkbcomp/geometry/HP cvs checkout: Updating xc/programs/xkbcomp/geometry/digital U xc/programs/xkbcomp/geometry/digital/Imakefile ... However when I make 'ls' no directory HP is there. Even though the directory HP doesn't exist any more it seems to be created temporarily and deleted afterwards. You can check out the HEAD as the 'full' version of the file in the repository file is always the HEAD version. I don't see a way how you can work around this as there seems to be no way to exclude files from checkout/update. One could create an alias module in the CVS repositry which excludes the HP directory. Like xc-win -a !xc/programs/xkbcomp/geometry/HP xc Then doing a cvs checkout xc-win may work. However I suspect that a 'cvs update' will still fail as this doesn't know about the module concept. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86AddInputHandler
Le mer 30/07/2003 à 16:36, Egbert Eich a écrit : > > One of the things I don't really get is what xf86AddInputHandler is > > supposed to be used for. Despite reading a lot of code and grepping > > multiple times, I found only very few locations using > > xf86AddInputHandler and I could not figure out what it is used for. I'd > > be most grateful for any kind of hint :) > > > > Please take a look at: > > http://xfree86.linuxwiki.org/xf86_2a_2a_20Functions Thanks for the pointer. This documentation is indeed useful but I had already figured what the function does by myself. I am more interested in what it is expected to be used for: who will call this function ? You could probably rephrase this to: "what is an Input Handler?". [EMAIL PROTECTED] Xserver]$ grep -r xf86AddInputHandler * hw/xfree86/common/xf86.h:pointer xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data); hw/xfree86/common/xf86Events.c:xf86AddInputHandler(int fd, InputHandlerProc proc, pointer data) hw/xfree86/drivers/glint/pm2_video.c: xf86AddInputHandler(xvipc_fd, Permedia2ReadInput, NULL); hw/xfree86/loader/xf86sym.c: SYMFUNC(xf86AddInputHandler) hw/xfree86/os-support/bsd/bsd_apm.c:APMihPtr = xf86AddInputHandler(fd, xf86HandlePMEvents, NULL); hw/xfree86/os-support/bsd/bsd_kqueue_apm.c:APMihPtr = xf86AddInputHandler(kq, xf86HandlePMEvents, NULL); hw/xfree86/os-support/linux/lnx_apm.c: APMihPtr = xf86AddInputHandler(fd,xf86HandlePMEvents,NULL); [EMAIL PROTECTED] Xserver]$ grep does not show any meaningful use of the function: I'd expect way more people to be interested in adding a fd to the list of fds to watch for in select. Is there another way to do this ? Obviously, I missed something rather fundamental about this code because I feel like I am going nowhere. regards, Mathieu -- Mathieu Lacage <[EMAIL PROTECTED]> ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, > I don't see a way how you can work around this as there seems to > be no way to exclude files from checkout/update. > One could create an alias module in the CVS repositry which excludes > the HP directory. Like > > xc-win -a !xc/programs/xkbcomp/geometry/HP xc > > Then doing a > cvs checkout xc-win > may work. However I suspect that a 'cvs update' will still fail as > this doesn't know about the module concept. Does this mean I can only get HEAD and new branches from it? I just tried to get the xf-4_3-branch and it has the same problem as the xf-4_3_0_1 tag. I just did this: [EMAIL PROTECTED] ~/x-devel/4.3 $ export [EMAIL PROTECTED]:/cvs [EMAIL PROTECTED] ~/x-devel/4.3 $ export CVS_RSH=ssh [EMAIL PROTECTED] ~/x-devel/4.3 $ cvs -z3 checkout -r xf-4_3-branch xc > cvs-checkout.log 2>&1 I got: U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory Does that mean that xf-4_3-branch will never work for Cygwin and that there is nothing we can do to ever fix this? If so, that is really a bummer. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 09:28:10PM +1000, Daniel Stone wrote: >On Wed, Jul 30, 2003 at 06:14:06AM -0500, Todd T. Fries wrote: >> Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: >> [..] >> | I did suggest this (mv hp,v hp.old,v). >> >> If you guys care about history at all, aka the ability to checkout files >> in the past, you would not suggest nor impement this suggestion. > >If anyone cared about it, they wouldn't still be using CVS, probably. :P What a ridiculous comment. Aside from this little problem, you can check out any any tagged release of XFree86 over the last 9 years. That you can do this is not an accident. (Versions before this were in a different respository.) This problem happened by going beyond CVS's limits. CVS works just fine (and predictably) providing its limits are understood and worked within. I'm not aware of a sufficiently free alternative that meets this minimum requirement. >Yes, but what's the alternate solution? I really don't like the changed-case >solution, as that sets a precedent of sorts. A note should be made somewhere of >the moved files. In this case I think XKB is flexible enough to allow the issue to be avoided. I'm going to see if I can change our 'cvs' so that it won't allow the changed-case "solution". David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 01:09:50PM -0400, Harold L Hunt II wrote: >Egbert, > > > I don't see a way how you can work around this as there seems to > > be no way to exclude files from checkout/update. > > One could create an alias module in the CVS repositry which excludes > > the HP directory. Like > > > > xc-win -a !xc/programs/xkbcomp/geometry/HP xc > > > > Then doing a > > cvs checkout xc-win > > may work. However I suspect that a 'cvs update' will still fail as > > this doesn't know about the module concept. > >Does this mean I can only get HEAD and new branches from it? I just >tried to get the xf-4_3-branch and it has the same problem as the >xf-4_3_0_1 tag. > >I just did this: > >[EMAIL PROTECTED] ~/x-devel/4.3 >$ export [EMAIL PROTECTED]:/cvs > >[EMAIL PROTECTED] ~/x-devel/4.3 >$ export CVS_RSH=ssh > >[EMAIL PROTECTED] ~/x-devel/4.3 >$ cvs -z3 checkout -r xf-4_3-branch xc > cvs-checkout.log 2>&1 > > >I got: > >U xc/programs/xkbcomp/geometry/hp >U xc/programs/xkbcomp/geometry/keytronic >U xc/programs/xkbcomp/geometry/kinesis >U xc/programs/xkbcomp/geometry/macintosh >U xc/programs/xkbcomp/geometry/microsoft >U xc/programs/xkbcomp/geometry/nec >U xc/programs/xkbcomp/geometry/northgate >U xc/programs/xkbcomp/geometry/pc >U xc/programs/xkbcomp/geometry/sony >U xc/programs/xkbcomp/geometry/sun >U xc/programs/xkbcomp/geometry/winbook >cvs [checkout aborted]: could not chdir to >xc/programs/xkbcomp/geometry/HP: Not a directory > > >Does that mean that xf-4_3-branch will never work for Cygwin and that >there is nothing we can do to ever fix this? > >If so, that is really a bummer. Be a little patient. This problem will be fixed, and in a way that minimises the impact on the history loss. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
Hannes Reinecke <[EMAIL PROTECTED]> wrote: > > Also, I think this is a different movie. The embbeded market is > > different to the desktop one. > > Hmm, have you tried asking trolltech? > After all, they did do the QT GUI for the Zaurus and presumably would need > to know how to access the framebuffer, this being embedded. So one would > assume that _some_ docs must have been available ... TrollTech uses the Linux framebuffer and does not have acceleration support except for a small number of sample drivers (Mach64, Matrox and Voodoo3). Hence if Qt works on that device, it just uses a dumb framebuffer and whatever is exported by the kernel via the framebuffer interface. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Compaq QVision 1280 (E)
Hi, There are rumors that the Compaq QVision 1280 cards were actually based on older Matrox chips (Athena)? Anybody know for sure? kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Compaq QVision 1280 (E)
[EMAIL PROTECTED] wrote: > There are rumors that the Compaq QVision 1280 cards were actually > based on older Matrox chips (Athena)? Anybody know for sure? No, that is not correct. The Compaq QVision 1024 and 1280 cards were Compaq original designs - I still have the specs for those beasts floating around out the back somewhere. The Compaq QVision 2000 card however was a new card that uses the Matrox Athena chipset. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
PRINTING PRODUCTS, Low Prices
56 Percent off all printer supplies Please come see this stores, feel what others have already, quality ink cartridges at a great price We can offer many brands including, Canon, Lexmark HP, and Epson http://thebestl1ttle1nkontheweb.com/neb.html choose to stop sending of all our mails, http://qual1ty1nks-wholesalepr1c1ng.com/s20.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes wrote: On Wed, Jul 30, 2003 at 01:09:50PM -0400, Harold L Hunt II wrote: Egbert, I don't see a way how you can work around this as there seems to be no way to exclude files from checkout/update. One could create an alias module in the CVS repositry which excludes the HP directory. Like xc-win -a !xc/programs/xkbcomp/geometry/HP xc Then doing a cvs checkout xc-win may work. However I suspect that a 'cvs update' will still fail as this doesn't know about the module concept. Does this mean I can only get HEAD and new branches from it? I just tried to get the xf-4_3-branch and it has the same problem as the xf-4_3_0_1 tag. I just did this: [EMAIL PROTECTED] ~/x-devel/4.3 $ export [EMAIL PROTECTED]:/cvs [EMAIL PROTECTED] ~/x-devel/4.3 $ export CVS_RSH=ssh [EMAIL PROTECTED] ~/x-devel/4.3 $ cvs -z3 checkout -r xf-4_3-branch xc > cvs-checkout.log 2>&1 I got: U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory Does that mean that xf-4_3-branch will never work for Cygwin and that there is nothing we can do to ever fix this? If so, that is really a bummer. Be a little patient. This problem will be fixed, and in a way that minimises the impact on the history loss. David David, Okay. For now I checked out xf-4_3-branch on a linux machine, tarred it, copied it to my Cygwin machine, and untarred it. This gives me a working repository, but ideally we will eventually fix this or at least try to prevent it from happening too often in the future. Thanks to everyone for their help, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 07:38:30AM +0200, Alexander Pohoyda wrote: >> Egbert Eich wrote: >> > CVSROOT: /home/x-cvs >> > Module name: xc >> > Changes by:[EMAIL PROTECTED] 03/06/20 06:15:33 >> > Log message: >> > - moving xkbcom/geometry/HP to xkbcom/geometry/hp doesn't seem to be >> > possible as CVS doesn't allow a directory to have the same name as >> > a deleted file. >> > Added files: >> > xc/programs/xkbcomp/geometry/HP/: >> > Imakefile hp omnibook > >I have developed the omnibook geometry and I have a new geometry for >the DELL Inspiron laptop. I'm not submitting the latter because I >would not like to see a new directory DELL there. >Why should some company names be capitalized and others not? > >Would it be possible to fix this issue on the repository side? I mean >manually delete files `hp' and `dell' and create directories instead? As has already been discussed, deleting these files from the repository makes it impossible to check out previous releases in their correct form. [I thought I already sent the following, but I haven't seen it come through.] Since XFree86 is a cross platform project, I think we need to avoid conflicts that affect platforms with case-insensitive filesystems. Since CVS doesn't allow directories with the same name as files that have existed at any time, that means that we can't create directories like this. So far, the best solution I can see is to remove the 'HP' directory from the repository. That will only impact the history of the last few snapshots. I think that's preferable to affecting the history of releases going back to 3.3. Unless someone comes up with a better solution, that's what I'm planning to do. Is there a reason why the extra geometry descriptions couldn't be added to the original 'hp' file instead of putting them in separate files in a subdirectory? XKB should allow multiple descriptions per file. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 over Firewire !
Hi Is there any way that XFree86 can be used over firewire connection between two computers ? One possible way is to use IP over Firewire, and use XFree86 over that, but the IP1394 is not very stable at present. Also, the benchmarks of that are very low. I want to use X directly over firewire so that stream of around 300 MB/s can be obtained. If someone can provide me links for this, i can write some code to make the pieces work. Thanks -Dwipal ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: >On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: >> >>I heard (second hand from via) that xfree86 2.3.99 has drivers >>for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a >>http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. >4.3.99.9 has a known build problem (which you're seeing). Either try >4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. BTW - how do I tell what version of cvs I got? // George -- GEORGE GEORGALIS, System Admin/Architectcell: 646-331-2027< Security Services, Web, Mail,mailto:[EMAIL PROTECTED] Multimedia, DB, DNS and Metrics. http://www.galis.org/george ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
On Wed, 30 Jul 2003 11:08:40 -0700 "Kendall Bennett" <[EMAIL PROTECTED]> (Bbabbled: (B (B> Hannes Reinecke <[EMAIL PROTECTED]> wrote: (B> (B> > > Also, I think this is a different movie. The embbeded market is (B> > > different to the desktop one. (B> > (B> > Hmm, have you tried asking trolltech? (B> > After all, they did do the QT GUI for the Zaurus and presumably would need (B> > to know how to access the framebuffer, this being embedded. So one would (B> > assume that _some_ docs must have been available ... (B> (B> TrollTech uses the Linux framebuffer and does not have acceleration (B> support except for a small number of sample drivers (Mach64, Matrox and (B> Voodoo3). Hence if Qt works on that device, it just uses a dumb (B> framebuffer and whatever is exported by the kernel via the framebuffer (B> interface. (B (Bare you sure they haven't written a custom acceleration support module for the (Bimageon just for sharp? they do own the copyright to their code.. so they never (Bhave to release it if they don't want to... (this kind of thing is done quite (Boften in the embedded market - there are custom add-ons and drivers for "a (B"normal" software package, just to make it work with the vendors esoteric (Bhardware) (B (Bi could definitely imaging this happening... (B (B> Regards, (B> (B> --- (B> Kendall Bennett (B> Chief Executive Officer (B> SciTech Software, Inc. (B> Phone: (530) 894 8400 (B> http://www.scitechsoft.com (B> (B> ~ SciTech SNAP - The future of device driver technology! ~ (B> (B> ___ (B> Devel mailing list (B> [EMAIL PROTECTED] (B> http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > > TrollTech uses the Linux framebuffer and does not have acceleration > > support except for a small number of sample drivers (Mach64, Matrox and > > Voodoo3). Hence if Qt works on that device, it just uses a dumb > > framebuffer and whatever is exported by the kernel via the framebuffer > > interface. > > are you sure they haven't written a custom acceleration support > module for the imageon just for sharp? Yes, I am sure. We are a development partner of Trolltech's ;-) Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI Imageon 100
On Wed, 30 Jul 2003 17:49:21 -0700 "Kendall Bennett" <[EMAIL PROTECTED]> (Bbabbled: (B (B> Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: (B> (B> > > TrollTech uses the Linux framebuffer and does not have acceleration (B> > > support except for a small number of sample drivers (Mach64, Matrox and (B> > > Voodoo3). Hence if Qt works on that device, it just uses a dumb (B> > > framebuffer and whatever is exported by the kernel via the framebuffer (B> > > interface. (B> > (B> > are you sure they haven't written a custom acceleration support (B> > module for the imageon just for sharp? (B> (B> Yes, I am sure. We are a development partner of Trolltech's ;-) (B (BAaah then I bow to your superior knowledge of the situation :) (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes <[EMAIL PROTECTED]> writes: > going back to 3.3. Unless someone comes up with a better solution, > that's what I'm planning to do. OK, it seems to be the best solution in this situation. I dare to propose another solution, however: to delete the `geometry' directory and created a new one (named `geometry2` or `geom` or whatever) which will have companies as lowercased directories. > Is there a reason why the extra geometry descriptions couldn't be added > to the original 'hp' file instead of putting them in separate files in > a subdirectory? XKB should allow multiple descriptions per file. Yes, that's right. This is not a limitaton of XKB. If you have a look into newly created geometry, you'll see that it already contains 3 sections, which are nested and re-used: 1. for the mouse stick 2. for the base frame and common buttons 3. for US keyboard layout. Some other geometries (like ibm/thinkpad) have also 4. for national layouts. I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) I'm open to suggestions. Thanks! -- Alexander Pohoyda <[EMAIL PROTECTED]> ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
