DEVICE ON/OFF
hi how can envoke the DEVICE ON/OFF signal in a input driver from out of a x- client application ... I want to start and stop a input driver and use that signal to start something else in the input driver ... then this has to happen each time i call DEVICE ON from a x- client application -- _ *Robert Woerle Linux Customer Support* *PaceBlade Technology Europe SA* phone: +49 89 552 99935 fax: +49 89 552 99910 mobile: +49 179 474 45 27 email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] web: http://www.paceblade.com _ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Someone has re-implemented ucs2any.pl in C
Mike A. Harris writes: On Wed, 11 Jun 2003, Matthias Scheler wrote: In the interests of portability--their base system doesn't ship with perl--the NetBSD people have implemented ucs2any.pl in C. There's a version at http://backyard.homeunix.net:8080/~ben/ucs2any/ I was the one who initiated rewriting ucs2any.pl as C program and would like to ask that this program is not intergrated into the XFree86 sources at the moment. The version available under the URL above is far from being usable at the moment: - It's not portable (non-ANSI C compliant, asprintf(3), etc.) - It crashes when used as a replacement for ucs2any.pl in a full build. I'm in the process of sorting these issue out with the author and will submit the program via [EMAIL PROTECTED] once the problems are fixed. I rewrote ucs2any in C about a year and a half ago, but I didn't finish doing the testing I planned to compare it between the perl version and my C version. Mine is entirely in ANSI C, and I had planned on submitting it to XFree86 for inclusion once I was sure it was a 100% safe replacment. After mentioning this to a few people, I was told not to bother because the fonts in 4.3.0 would be re-encoded on the fly, or would be ttf bitmaps so ucs2any wouldn't be needed anymore anyway, so I just dropped it and left it in limbo since. I'd be more than happy to finish off the final touches, test it on all bdf fonts I've got available, and compare the output against ucs2any.pl if it would be useful to XFree86 project or anyone else. My C version can process all fonts in one pass and spit out multiple encodings all at once, instead of being invoked hundreds of times. I wrote it like that as I figured it might give an additional speedup not having to fork and exec from a shell script constantly. Yes, there are plans to ship all bitmap fonts converted to ttf. This however requires bdf-ttf and ttf-bdf converters. I don't know the status of these converters. Even then we'd still need bitmap fonts in different encodings for systems that still require the old bitmap renderers for some reason. Therefore a ucs2any converter written in C will be useful in any case. If you want to invest the time to test the results of your converter against the perl version I'd think it would make sense to switch to it. Could you post the code of the converter to the bugzilla? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Someone has re-implemented ucs2any.pl in C
On Thu, 12 Jun 2003, Egbert Eich wrote: Yes, there are plans to ship all bitmap fonts converted to ttf. This however requires bdf-ttf and ttf-bdf converters. I don't know the status of these converters. Even then we'd still need bitmap fonts in different encodings for systems that still require the old bitmap renderers for some reason. Therefore a ucs2any converter written in C will be useful in any case. If you want to invest the time to test the results of your converter against the perl version I'd think it would make sense to switch to it. Could you post the code of the converter to the bugzilla? Ok, I'll go ahead and finish off fixing the last few quirks and test it. Once I've quality/sanity tested it I'll submit it to bugzilla and likely post a comment here also. It should be portable to any platform which adheres to ISO C99 and SuSv3, but I'll be more than glad to fix any portability issues to other platforms as well if any issues pop up. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Someone has re-implemented ucs2any.pl in C
On Thu, Jun 12, 2003 at 01:00:46PM -0400, Mike A. Harris wrote: I rewrote ucs2any in C about a year and a half ago, but I didn't finish doing the testing I planned to compare it between the perl version and my C version. Mine is entirely in ANSI C, and I had planned on submitting it to XFree86 for inclusion once I was sure it was a 100% safe replacment. The ucs2any.c mentioned in this thread is now pure ANSI C, too, and passes a full XFree86 build. Once I've done something on the generated files I'll commit it to the NetBSD sources for general exposure. Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Getting Dual Independent Heads to work on Debian(sid) on iBook
there are alot of issues with dualhead and LCDs on PPC. I believe the fix is to use fbdev, but I'm not sure anyone has gotten dualhead to work yet. check the archives from last month. Alex --- Andreakis, Dean (MED) [EMAIL PROTECTED] wrote: I am trying to enable dual independent heads on my iBook that has Debian(sid) installed and XFree86 4.3.0. The iBook has an ATI Mobility Radeon 7500 (M7) installed. In order to alleviate configuration issues I set the same mode up successfully on my Dell laptop with RH9 installed that also has the same ATI video chip and XFree86 4.3.0. I then just used the same basic changes I made to the Dell/RH9 XF86Config file on the iBook/Debian system. When I did this the iBook basically just cloned the display to the external CRT instead of providing a second independent coordinate system on the external CRT like I wanted. Here is my XF86Config-4 file on the iBook: Section Files RgbPath /usr/X11R6/lib/X11/rgb FontPath unix/:7100 EndSection Section Module Load dbe Load GLcore Load extmod # Load fbdevhw Load glx Load record Load freetype Load type1 Load dri Load xtrap Load speedo EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout us EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol IMPS/2 Option Device /dev/input/mice Option ZAxisMapping 4 5 Option Emulate3Buttons no EndSection Section InputDevice Identifier DevInputMice Driver mouse Option Protocol IMPS/2 Option Device /dev/input/mice Option ZAxisMapping 4 5 Option Emulate3Buttons no EndSection Section Monitor Identifier lcd VendorName Generic ModelName Flat Panel 1400x1050 Option dpms EndSection Section Monitor Identifier external-21in VendorName Monitor Vendor ModelNameDell 1800FP (Analog) Option dpms EndSection Section Device Identifier radeon-lcd VendorName ATI BoardName ATI Radeon Driver radeon Screen 0 #BusID PCI:0:16:0 #Option UseFBDev EndSection Section Device Identifier radeon-external VendorName ATI BoardName ATI Radeon Driver radeon Screen 1 BusID PCI:0:10:0 EndSection Section Screen Identifier lcd-screen Device radeon-lcd Monitor lcd DefaultDepth 24 Subsection Display Depth 8 Modes 1024x768 800x600 640x480 EndSubsection Subsection Display Depth 15 Modes 1024x768 800x600 640x480 EndSubsection Subsection Display Depth 16 Modes 1024x768 800x600 640x480 EndSubsection Subsection Display Depth 24 Modes 1024x768 800x600 640x480 EndSubsection EndSection Section Screen Identifier external-21in-screen Device radeon-external Monitor external-21in DefaultDepth 24 SubSection Display Depth24 Modes1024x768 800x600 640x480 EndSubsection EndSection # Dual-head layout with a large monitor on the right of the LCD. # Really this layout will work for any monitor that supports DDC # queries. It may give you a higher resolution than you'd prefer though. Section ServerLayout Identifier default InputDevice Keyboard0 CoreKeyboard InputDevice Mouse0 CorePointer InputDevice DevInputMice SendCoreEvents Screen lcd-screen Screen external-21in-screen LeftOf lcd-screen EndSection Section DRI Group0 Mode 0666 EndSection The only odd behaviour I have noticed is around the BusID settings (in the Device section) between the iBook and the Dell: 1. On the Dell system I set the BusID to the same value (as reported by lspci or X --scanpci) in both Device sections and everything is ok. 2. On the iBook if I set both BusID's in both device sections to 0:10:0 then X won't startup even though this is the ID reported by lspci for the ATI chip. If I just set the BusID in the device section associated with the external CRT to 0:10:0 then X will start and the colors are ok but there are scrolling lines in the lcd panel. Also, if I run glxinfo then it reports information on just one screen even though I have defined two of them. 3. If both are set to BusID 0:16:0 (or just the device section associated with the external CRT) then X starts but both screens are yellowish and there are scrolling lines in the lcd panel. Also, if I run glxinfo then it reports information on two screens (as I expect). From previous mailing list responses around this
Re: Someone has re-implemented ucs2any.pl in C
On Thu, Jun 12, 2003 at 09:44:28PM +0200, Matthias Scheler wrote: The ucs2any.c mentioned in this thread is now pure ANSI C, too, and passes a full XFree86 build. Once I've done something on the generated files I'll commit it to the NetBSD sources for general exposure. The ucs2any utility is now available in NetBSD's source repository (e.g. via anonymous CVS): Module Name:xsrc Committed By: tron Date: Thu Jun 12 22:49:27 UTC 2003 Modified Files: xsrc/xfree/xc/config/cf: X11.tmpl xsrc/xfree/xc/fonts: Imakefile xsrc/xfree/xc/fonts/util: Imakefile Added Files: xsrc/xfree/xc/fonts/util: ucs2any.c Log Message: Add C implementation of ucs2any utility contributed by Ben Collver. This allows us to build all international fonts with requiring Perl 5. To generate a diff of this commit: cvs rdiff -r1.4 -r1.5 xsrc/xfree/xc/config/cf/X11.tmpl cvs rdiff -r1.3 -r1.4 xsrc/xfree/xc/fonts/Imakefile cvs rdiff -r1.3 -r1.4 xsrc/xfree/xc/fonts/util/Imakefile cvs rdiff -r0 -r1.1 xsrc/xfree/xc/fonts/util/ucs2any.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. I'll submit to [EMAIL PROTECTED] once it got tested properly. Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Getting Dual Independent Heads to work on Debian(sid) on iBook
I dont really know driver or chipset in detail, but its the way that it needs programming so that the timing for the LCD does match. black or striped or whatever effects do indcate wront timing for the flat pane display. If the device is capable of dual head in other OS condtions then it can do it with Linux as well. Current AGP grafics chipsets in PCs do expose device 1:0:0 and 1:0:1 with different IDs (on AMD boards the 2nd number is higher). for real programming the first is preferable. in other words the driver must be capable of doing two outputs in parallel or it will only drive both outputs with identical timings and same contents. its a single graphics core and does need at least one output unit programmed. if neither of the driver does know about the other then there is a serious problem because they will heavily fight for the same output timing registers. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Symbol unresolved problems..
Hi... I modified xfree 4.3.?and successfuly compiledandinstalled it. When I start X, I got some messages like "Symbol x in module x is not resolved". What is the main reason of these problems? What cause it? thank you..
Re: Symbol unresolved problems..
Do you have a specific example? Are these symbols in your modifications? You can't call anything you like from within an XFree86 module. They don't, for instance, link against libc. There are only specific functions you can call - ones exported by the core server. Mark. On Thu, 12 Jun 2003, Jason Kim wrote: Hi... I modified xfree 4.3.? and successfuly compiled and installed it. When I start X, I got some messages like Symbol x in module x is not resolved. What is the main reason of these problems? What cause it? thank you.. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Symbol unresolved problems..
Thank you ... No I didn't modify this symbol.. This symbol is vbeFree. I didn't touch anything about Savage device driver, but savage_driver.o module can't resolve the vbeFree symbol anymore... T.T jason - Original Message - From: Mark Vojkovich [EMAIL PROTECTED] To: Jason Kim [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 9:34 PM Subject: Re: Symbol unresolved problems.. Do you have a specific example? Are these symbols in your modifications? You can't call anything you like from within an XFree86 module. They don't, for instance, link against libc. There are only specific functions you can call - ones exported by the core server. Mark. On Thu, 12 Jun 2003, Jason Kim wrote: Hi... I modified xfree 4.3.? and successfuly compiled and installed it. When I start X, I got some messages like Symbol x in module x is not resolved. What is the main reason of these problems? What cause it? thank you.. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
