RE: User sponsored drivers
Surely it'd be less difficult nowadays, with the job market in its current state? Rob > > On Tue, 15 Jul 2003, Alex Deucher wrote: > > > This proposal comes up periodically on this and other xfree lists, but > > never really goes anywhere. Why not raise money from the open source > > community to fund open source driver development? > > > It is very difficult to convert money into code. It's probably > easier to raise the money than it is to find a way to convert > that into code. > > Mark. > > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: User sponsored drivers
On Tue, 15 Jul 2003, Mark Vojkovich wrote: > It is very difficult to convert money into code. It's probably > easier to raise the money than it is to find a way to convert > that into code. Not exactly a driver, but I was under the impression that remote GLX support (ie hardware accelerated 3D display on one machine for a client app running on another machine) was only pulled because none was prepared to pay for the work to be done. My understanding was that there is a company (Tungsten Graphics ?) who had the skill and the plan to do this whenever someone paid them. Or are drivers different because of the need for low-level hardware details ? -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Tutorials
Where can I find good tutorials for development with xlib. ___ Yahoo! Mail Mais espaço, mais segurança e gratuito: caixa postal de 6MB, antivírus, proteção contra spam. http://br.mail.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: linux 2.6 atkbd ==> xkb
> "Ivan" == Ivan Pascal <[EMAIL PROTECTED]> writes: >> What I cannot find is *where* those fake scancodes are generated >> and how they are mapped to 0x81-0x84 Ivan> xc/programs/Xserver/hw/xfree86/common/xf86Events.c Ivan> xf86PostKbdEvent() subroutine Ok. From that it looks like I need e0/01 thru e0/04, but as far as I can tell, X does not see real raw codes from linux, but must reverse engineer them. There is no general pattern from actual raw codes received by linux, the value linux covnerts the raw code to, and X's keycode. Eg, the 3 inet keys that still work are: Key Raw atk X11 - - --- --- VolUp e0/32 115 176 VolDn e0/21 114 174 Mutee0/23 113 160 If xf86PostKbdEvent() is adding 0x78 to the 2nd octet of a e0/xx sequence and keycode=scanCode + MIN_KEYCODE (aka 8), that means 0x80 is getting added to the 2nd octet to make the keycode, so X is seeing a scanCode of e0/48, e0/46 & e0/32 for those three. So where does 113,114,115 turn into e0/32, e0/46, e0/48 ? And what would turn into e0/01 thru e0/04 ? Apologies for being confused by this code. >> How do I get both us(pc105) and inet(inspiron)? Ivan> Simply use the second way. If the model name is the same as one Ivan> of inet file sections name, XKB uses us(pc105) map and _adds_ Ivan> inet(model_name) to it. (I mean XFree86 4.3.0. In previous Ivan> versions it uses us(pc104). ) Cool. Good to know. -JimC ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: User sponsored drivers
What about tungsten graphics or Providenza & Boekelheide, Inc. (Tim Robert's company? Plus I'm sure there are other small development companies that would be interested. Alex --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: > On Tue, 15 Jul 2003, Alex Deucher wrote: > > > This proposal comes up periodically on this and other xfree lists, > but > > never really goes anywhere. Why not raise money from the open > source > > community to fund open source driver development? > > > It is very difficult to convert money into code. It's probably > easier to raise the money than it is to find a way to convert > that into code. > > Mark. > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: User sponsored drivers
Support for HW accelerated indirect rendering is just a matter of restructuring some library interfaces so that GLX commands can get decoded and sent to the hardware rather than the sw renderer. It's in the pipeline for future development by the DRI folks, but if it were sponsored, it might happen sooner. there would be few if any changes needed in the hardware drivers. Alex --- Andrew C Aitchison <[EMAIL PROTECTED]> wrote: > On Tue, 15 Jul 2003, Mark Vojkovich wrote: > > > It is very difficult to convert money into code. It's probably > > easier to raise the money than it is to find a way to convert > > that into code. > > Not exactly a driver, but I was under the impression that remote GLX > support (ie hardware accelerated 3D display on one machine for a > client > app running on another machine) was only pulled because none was > prepared > to pay for the work to be done. My understanding was that there is a > company (Tungsten Graphics ?) who had the skill and the plan to do > this > whenever someone paid them. > > Or are drivers different because of the need for low-level hardware > details ? > > -- > Andrew C Aitchison > __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: User sponsored drivers
On Mer, 2003-07-16 at 15:08, Alex Deucher wrote: > Support for HW accelerated indirect rendering is just a matter of > restructuring some library interfaces so that GLX commands can get > decoded and sent to the hardware rather than the sw renderer. It's in > the pipeline for future development by the DRI folks, but if it were > sponsored, it might happen sooner. there would be few if any changes > needed in the hardware drivers. I never understood why XFree86 couldnt simply fork() a DRI client and forward the stream ? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: User sponsored drivers
On Wed, Jul 16, 2003 at 04:36:33PM +0100, Alan Cox wrote: >On Mer, 2003-07-16 at 15:08, Alex Deucher wrote: >> Support for HW accelerated indirect rendering is just a matter of >> restructuring some library interfaces so that GLX commands can get >> decoded and sent to the hardware rather than the sw renderer. It's in >> the pipeline for future development by the DRI folks, but if it were >> sponsored, it might happen sooner. there would be few if any changes >> needed in the hardware drivers. > >I never understood why XFree86 couldnt simply fork() a DRI client and >forward the stream ? That approach has been suggested several times over the last couple of years. I haven't seen anything to say that it wouldn't be a feasible solution (looks like the obvious approach to me). I think it's just one of those things where nobody has needed it enough to actually implement it. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
-fexeptions in library build rules with callbacks
We have a bug report at http://bugs.xfree86.org/show_bug.cgi?id=503 that suggests that when building libraries with callbacks using gcc the option -fexeptions should be used. It enables C++ programs to catch the exceptions. I've talked to a gcc expert and he says that using this option is sane. It adds unwind information and on some targets it supresses a few optimizations that break unwinding, however these optimizations are no big deal. In statically linked binaries the exception tables should automatically be removed if the binary does not use them. Any opinions? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -fexeptions in library build rules with callbacks
On Wed, 2003-07-16 at 13:11, Egbert Eich wrote: > We have a bug report at > > http://bugs.xfree86.org/show_bug.cgi?id=503 > > that suggests that when building libraries with callbacks using gcc > the option -fexeptions should be used. It enables C++ programs > to catch the exceptions. > I've talked to a gcc expert and he says that using this option is > sane. It adds unwind information and on some targets it supresses > a few optimizations that break unwinding, however these optimizations > are no big deal. > In statically linked binaries the exception tables should > automatically be removed if the binary does not use them. Is this useful if the libraries don't properly handle exceptions being thrown through them? I'd really suspect that most/all places where there are callbacks in the X libraries they will leak memory / corrupt state / otherwise misbehave if you throw an exception from a callback and catch it in the surrounding code. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tutorials
On Wed, 16 Jul 2003, [iso-8859-1] Mathias Brito wrote: > Where can I find good tutorials for development with xlib. Kenton Lee's big X site: http://www.rahul.net/kenton/xsites.framed.html Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tutorials
On Wed, Jul 16, 2003 at 10:08:43AM -0300, Mathias Brito wrote: > Where can I find good tutorials for development with xlib. > Don't forget the first rule of Xlib, "use a toolkit instead," unless you're implementing a toolkit or window manager or something. Havoc ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: linux 2.6 atkbd ==> xkb
Hi, > >> What I cannot find is *where* those fake scancodes are generated > >> and how they are mapped to 0x81-0x84 > > Ivan> xc/programs/Xserver/hw/xfree86/common/xf86Events.c > Ivan> xf86PostKbdEvent() subroutine > > Ok. From that it looks like I need e0/01 thru e0/04, but as far as I > can tell, X does not see real raw codes from linux, but must reverse > engineer them. Excuse me, you are talking something about raw-codes, emulated scan-codes and X's keycodes, etc. but I still can't (my fault) understand what codes you have and what keycodes you want to get from the Xserver. Let me explain. 1. Xserver gets key codes from the 'system' keyboard driver. 2. The system keyboard driver (that works in a 'console' mode) was firstly designed for an AT keyboard. I means it produces simple one-byte scan-codes for most of keys (such as alphabetic keys) and 'extended scan-codes' that are a prefix code 0xE0 and some other code, for some additional keys. 3. The X's keyboard driver has to convert all scancodes it get from the system driver to one-byte codes named "keycodes". 4. The X's driver assumes that one-byte scan-codes don't cover all range of one-byte values (0-255) and there is some gap of such values that can be used for the 'extended' scan-codes. Therefore it converts 0xE0+smth extended scan-codes to one-byte codes that (as it assumes) can't be generated by a keyboard as one-byte sacn-codes. For such conversion the X's driver uses a 'switch' statement although a simple table can be used for that task. Unfortunately, keyboards that have some extra keys (such as 'Internet keys') can generate for such keys one-byte scan-codes which are codes from the range that Xserver driver uses for the extended keys. Thus the algorithm of the X's keyboard driver is: - get a scan-code from the sytem driver - if it is 0xE0 code, remember this fact and get the next code - if a code is a continuation of an extended scan-code (0xe0 is already received) recode it to some one-byte code using a special table (actually a switch statement does it); - if the code is a single one-byte code there are two ways - if it isn't one that can fall into range used for a representation of the extended scan-codes, it goes to the next step without any changes - otherwise (the code is one from range of the values used for a representation of extended scancodes) it is also converted to some other code (by a switch statement). And finaly the the X's keyboard driver adds 8 to each code got from the previous step. Lets return to your Linux. If it use non-AT keyboard the Linux keyboard driver anyway emualtes 'raw scan-codes' as if they are got from an AT keyboard. Thus if it emulates for additional keys (that the current X's driver doesn't recognize) extended scan-codes, you have to update the table (actually a 'switch' statement) that converts extended scan-codes to X's keycodes. But if the system driver emulates for the extra keys one-byte codes: - you should do nothing (but remember that the keycodes the Xserver generates are greater by 8 than the sacn-code it got from the 'system' driver) - or (if the keys ommit the keycodes that are in range used for extended scan-codes) update the table (a 'switch' operator again) that converts such codes to another ones that are not used for a representation of the extended scan-codes. And now, what do you have and what do you want? What codes the Linux driver emulates for your extended keys? What problem do you have with their conversion to keycodes? What keycodes you would like to have for your keys? -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: linux 2.6 atkbd ==> xkb
> "Ivan" == Ivan Pascal <[EMAIL PROTECTED]> writes: Ivan> 1. Xserver gets key codes from the 'system' keyboard driver. Here is the issue. Linux does not pass on the kb's scan codes. The input layer, AFAICT, *always* cooks the scancodes into an 8 bit code per key. The tables for AT type 2 and AT type 3 kbs are in the file linux-2.5/drivers/input/keyboard/atkbd.c. As an example, the ESC key generates scan code 0x76. In atkbd.c that is translated into 1. That gets passed to X w/o change and X converts that to keycode 9. All good. For VolUp, 0xe0/0x32 goes to 115, 115 somehow gets translated into 48 and X translates 48 into 48+0x78+8 or 176. Again all is good as xkb expects keycode 176 for VolUp. I've also since found that a value in the table in atkbd.c of 92 results in X keycode 129 and that 94 results in keycode 131. Those are what inet(inspiron) expects for Play and Prev. Obviously 92 gets translated to 0xe0/0x01 and 94 to 0xe0/0x03, since those are what X translates to 129 and 131. But even though 92 ==> 129 and 94 ==> 131, 93 and 95 do not end up at 130 and 132. 93 must get converted to 0xe0/0x77 as the keycode is 247. As for 95, that ends up with keycode 98 The steps 2 thru 4 as you described I did grok, in part from your first reply. It was helpful. Ivan> Lets return to your Linux. If it use non-AT keyboard the Linux Ivan> keyboard driver anyway emualtes 'raw scan-codes' as if they are Ivan> got from an AT keyboard. I haven't found any code in 2.5 (I should say 2.6 now) where a translation back to raw scan codes occurs. I was presuming X was doing that. The only thing I can find is the tables used to convert from raw scan codes to the codes corresponding to the symbols #defined in linux-2.5/include/linux/input.h. So the question now boils down to: How are the linux-2.6 input system keycodes translated back to pseudo AT type 2 style 'raw codes' so that X can convert those 'raw codes' into X keycodes? As a side question: will a driver that just reads /dev/input/eventX and converts from those codes directly to xkb symbols be the better option? -JimC ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: aid for TODO tasks offered
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 30 June 2003 18:55, Egbert Eich wrote: > silicon motion beneath my current qnx/sh4 patches, i have a little update for the smi card. may be i can add: - dma - XvMC as well later any participants ? cheers, sven btw: if i have brought the qnx/sh4 patches to a stable state, - to whom should i send this patch ? - how should i make the diff ? - using cvs against repository, or - cvs update against rep. and diff locally after testing ? i would prefer the later, 'cause then i do know, it might work ;-) after testing. cheers, sven -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/FiU8HdOA30NoFAARAp+PAKC0qgTuRZW1bbMPpttRJyWWvxJa5wCfbTh/ A213fu2mSdftEwLiXyPp4wk= =CpTC -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
