Re: siliconmotion CSync output ?
I used your vclk setting code as in smi_driver.c, and changed the shift in SMI_CommonCalcClock() but it seems to still have some issue. 12220 clock gives me values of SR6C: 63, SR6D: 1D bruno On Sun, 11 Mar 2007, Alex Deucher wrote: On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote: I looked at that diff and it looks like what I added, except that I also set bits 7:6 of CCR68 to 01 because the doc I have says that will select VCLK from the programmable VCLK regs, CCR6C and CCR6D. I fixed the vclk problem. The postscalar shift was wrong in SMI_CalcClocks(). either grab my updated tree or change the shift from 6 to 7. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On Mon, 12 Mar 2007, Alex Deucher wrote: On 3/12/07, bruno schwander [EMAIL PROTECTED] wrote: I used your vclk setting code as in smi_driver.c, and changed the shift in SMI_CommonCalcClock() but it seems to still have some issue. 12220 clock gives me values of SR6C: 63, SR6D: 1D That's going to give you a vclk of ~48.88 Mhz yeah, I know. I meant that SMI_CommonCalcClock should have come up with different values, instead it returned the values above. Unfortunately, the min clock on the smi is 20 Mhz (although I'd think hmm that would be really annoying...where do you get that ? I can't find any mention of such a limitation. Just the hope that given the right SR6C/D values, I can get any corresponding dot clock :-) I did chnge the minclock values so that it accepts lower clock requests, but I have not checked it it actually generates those frequencies. Need the scope... you should be able to get down to at least the reference clock), so that may be causing a problem in the calculation function. If you want to calculate the clock yourself you can use the following formula: VCLK = 14.31818 Mhz * (VNR/VDR) * (1/(1 + PS)) VNR being SR6C and VDR and SR6D. PS is bit 7 of SR6D. the spec I have for the smi712 (lynxEM+) says bit 7 and 6 are PS, as follows: bit 6 bit 7 vclk 0 0 PS not enabled, programmed vclk 0 1 PS enabled, vclk = 1/2 programmed vclk 1 0 PS enabled, vclk = 1/4 prog vlck 1 1 PS enabled, vclk = 1/8 prog vlck bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
in SMI_Save(), SR6C and SR6D (and SR68) are saved only if pSmi-Dualhead, why ? seems it should always be done ? in SMI_WriteMode, those 2 are written twice, once everytime + once if pSmi-Dualhead What's your take about CCR68 (SR68), also written only in dualhead mode... seems if SR6C/SR6D are to be active, SR68 has to be configured too. bruno On Fri, 9 Mar 2007, Alex Deucher wrote: On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: On Fri, 9 Mar 2007, Alex Deucher wrote: The latest version of the siliconmotion driver in xorg git head should have the lockup fix you need. The problem is the engine doesn't need to be synced until it has been started. I've also added dualhead support. I haven't yet pushed the pll fix, that's still in my local tree at home along with some other stuff I'm working on. I can send you a patch later if you want. that would be awesome, yes ! so far what I added (enabling in CCR68 vclock scaled from CCR6C and CCR6D) crashes my pc... I used SMI_CommonCalcClock() but I get wrong values back for the register values. I am certainly not calling it right. I just put my local tree up here: http://gitweb.freedesktop.org/?p=users/agd5f/xf86-video-siliconmotion.git;a=summary The relevant commit is a328d4378c28b788acf320bee9fbdfd129e0923d I haven't tested any of this new code yet, so YMMV. I haven't had time this week and I need to rebuild my laptop with the smi chip, but I hope to do that this weekend, at which point I should be able to sort out any bugs. Let me know if you haven any questions. Alex bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On Fri, 9 Mar 2007, Alex Deucher wrote: On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: so I gather now that actually I should leave the xf86SetCrtcForModes() alone, and just add setting the clock with CCR6C, CCR6D (and enabling it with CCR68). I'll see how that goes... exactly. Sorry for not responding earlier. You can use the SMI_CalcClock() function to calculate SR6C and SR6D, just like the mclk is generated. Use mode-Clock. I have a similar patch in my xorg smi tree. which xorg version are you up to, that has that patch ? did you mean it is not comitted yet ? I can't get the latest either xfree86 or xorg to work at all on that board I have with the smi712. I am testing currently with xorg 6.8.2 because that is the one that still works. I will test and fold in xfree86 4.5 but so far 4.6 does not work for me either. bruno Alex bruno On Thu, 8 Mar 2007, bruno schwander wrote: On Thu, 8 Mar 2007, Alex Deucher wrote: The siliconmotion driver doesn't explicitly set the vclk pll. It uses the bios (if UseBIOS is set or does nothing if not). that is what I was wondering... well, if I do not Options UseBIOS false all I get is a blank screen. So I have to disable it. I did not realize that it did not set the pixel clock since when using a default VGA 640x480 resolution, it was working. So I guess it just happens to stay at whatever pixel clock the BIOS or console driver had set it to ? That seems very strange. It's trivial to add however. SR6C, SR6D are programmed similarly to the mclk. I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was really set. All this makes more sense now. So what you are saying is that in smi_driver.c : SMI_PreInit(), I should replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that programs vclk explicitely ? How can it set the crtc for several modes ? That is what xf86SetCrtcForModes() seems to do, right ? I still have a lot to learn. thanks for all the help guys, trudging along... bruno Alex Bruno On Wed, 7 Mar 2007, bruno schwander wrote: ah actually now it is not choosing my modeline and I do not understand why: (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz (II) Silicon MotionClock range: 14.00 to 135.00 MHz (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz (II) Silicon MotionNot using mode 640x480i (vrefresh out of range) (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz (II) Silicon MotionNot using default mode 640x350 (vrefresh out of range) vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz vrefresh, rejected ? the modeline is as follows: ModeLine 640x480i 24.44 640 680 728 776 480 480 484 525 Interlace Composite bruno On Wed, 7 Mar 2007, bruno schwander wrote: I think I figured it out, however it seems that although my modeline includes 'composite' DisplayModePtr mode-Flags V_CSYNC does not evaluate to true. I assume as long as the 'composite' keyword is found on the modeline, the flag should be set, right ? I need to add some debug messages, but this seems a little strange. Is there something else that needs to be configured, like telling that the driver actually supports the composite keyword on the modeline ? On a different note, the latest X release does not seem to work on that chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test this stuff. I figure XFree86 4.5 should work, but 4.6 does not. I'll provide patches to all and note on which version it was tested of course, once it works :-) bruno On Tue, 27 Feb 2007, Marc Aurele La France wrote: On Sun, 25 Feb 2007, bruno schwander wrote: On Fri, 23 Feb 2007, Marc Aurele La France wrote: On Thu, 22 Feb 2007, bruno schwander wrote: A little background: I have a single board PC with a SMI712 (lynxEM+) graphic chipset. X works like a charm. The driver currently ignores the V_CSYNC mode flag, so you would need to come up with a source patch to change that. I'd be happy to provide a patch, if I can figure where to put that. Since it is only a matter of setting one register it should be simple enough. I have (had?) no idea where to start, I'll grep for V_CSYNC and see... An appropriate spot for such changes would be after calls to vgaHWInit(), which, in this case, is in SMI_ModeInit(). Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard
Re: siliconmotion CSync output ?
On Fri, 9 Mar 2007, Alex Deucher wrote: The latest version of the siliconmotion driver in xorg git head should have the lockup fix you need. The problem is the engine doesn't need to be synced until it has been started. I've also added dualhead support. I haven't yet pushed the pll fix, that's still in my local tree at home along with some other stuff I'm working on. I can send you a patch later if you want. that would be awesome, yes ! so far what I added (enabling in CCR68 vclock scaled from CCR6C and CCR6D) crashes my pc... I used SMI_CommonCalcClock() but I get wrong values back for the register values. I am certainly not calling it right. bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
I looked at that diff and it looks like what I added, except that I also set bits 7:6 of CCR68 to 01 because the doc I have says that will select VCLK from the programmable VCLK regs, CCR6C and CCR6D. I'll get git and give your tree a try, thanks bruno On Fri, 9 Mar 2007, Alex Deucher wrote: On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: On Fri, 9 Mar 2007, Alex Deucher wrote: The latest version of the siliconmotion driver in xorg git head should have the lockup fix you need. The problem is the engine doesn't need to be synced until it has been started. I've also added dualhead support. I haven't yet pushed the pll fix, that's still in my local tree at home along with some other stuff I'm working on. I can send you a patch later if you want. that would be awesome, yes ! so far what I added (enabling in CCR68 vclock scaled from CCR6C and CCR6D) crashes my pc... I used SMI_CommonCalcClock() but I get wrong values back for the register values. I am certainly not calling it right. I just put my local tree up here: http://gitweb.freedesktop.org/?p=users/agd5f/xf86-video-siliconmotion.git;a=summary The relevant commit is a328d4378c28b788acf320bee9fbdfd129e0923d I haven't tested any of this new code yet, so YMMV. I haven't had time this week and I need to rebuild my laptop with the smi chip, but I hope to do that this weekend, at which point I should be able to sort out any bugs. Let me know if you haven any questions. Alex bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On Thu, 8 Mar 2007, Tim Roberts wrote: bruno schwander wrote: ah never mind. since this is interlaced, the pixel clock needs to be half that to get the right frame refresh rate (60Hz) with a pixel clock of 12.22MHz, it passes. Now, I am not sure if the pixel clock is effectively set to that, and my lcd still does not sync, so either the pixel clock is not set right or the SMI712 is not outputting composite sync (despite my hack to enable it) You have an LCD that expects 640x480 interlaced? Really? RGB input, 640x480 interlaced, composite sync. yes, it expects that and can't take anything else when in RGB mode. It can take a composite signal too, and outputs v/h sync pulses to synchronize overlaying with RGB signals, in that mode RGB inputs are 2v and digtal. Or it can be switched to RGB but requires composite sync in that case. strange beast indeed. Usually for DVD players with some microcontroller generating some on-screen display I believe. Bruno -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On Thu, 8 Mar 2007, Alex Deucher wrote: The siliconmotion driver doesn't explicitly set the vclk pll. It uses the bios (if UseBIOS is set or does nothing if not). that is what I was wondering... well, if I do not Options UseBIOS false all I get is a blank screen. So I have to disable it. I did not realize that it did not set the pixel clock since when using a default VGA 640x480 resolution, it was working. So I guess it just happens to stay at whatever pixel clock the BIOS or console driver had set it to ? That seems very strange. It's trivial to add however. SR6C, SR6D are programmed similarly to the mclk. I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was really set. All this makes more sense now. So what you are saying is that in smi_driver.c : SMI_PreInit(), I should replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that programs vclk explicitely ? How can it set the crtc for several modes ? That is what xf86SetCrtcForModes() seems to do, right ? I still have a lot to learn. thanks for all the help guys, trudging along... bruno Alex Bruno On Wed, 7 Mar 2007, bruno schwander wrote: ah actually now it is not choosing my modeline and I do not understand why: (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz (II) Silicon MotionClock range: 14.00 to 135.00 MHz (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz (II) Silicon MotionNot using mode 640x480i (vrefresh out of range) (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz (II) Silicon MotionNot using default mode 640x350 (vrefresh out of range) vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz vrefresh, rejected ? the modeline is as follows: ModeLine 640x480i 24.44 640 680 728 776 480 480 484 525 Interlace Composite bruno On Wed, 7 Mar 2007, bruno schwander wrote: I think I figured it out, however it seems that although my modeline includes 'composite' DisplayModePtr mode-Flags V_CSYNC does not evaluate to true. I assume as long as the 'composite' keyword is found on the modeline, the flag should be set, right ? I need to add some debug messages, but this seems a little strange. Is there something else that needs to be configured, like telling that the driver actually supports the composite keyword on the modeline ? On a different note, the latest X release does not seem to work on that chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test this stuff. I figure XFree86 4.5 should work, but 4.6 does not. I'll provide patches to all and note on which version it was tested of course, once it works :-) bruno On Tue, 27 Feb 2007, Marc Aurele La France wrote: On Sun, 25 Feb 2007, bruno schwander wrote: On Fri, 23 Feb 2007, Marc Aurele La France wrote: On Thu, 22 Feb 2007, bruno schwander wrote: A little background: I have a single board PC with a SMI712 (lynxEM+) graphic chipset. X works like a charm. The driver currently ignores the V_CSYNC mode flag, so you would need to come up with a source patch to change that. I'd be happy to provide a patch, if I can figure where to put that. Since it is only a matter of setting one register it should be simple enough. I have (had?) no idea where to start, I'll grep for V_CSYNC and see... An appropriate spot for such changes would be after calls to vgaHWInit(), which, in this case, is in SMI_ModeInit(). Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
I keep answering my own questions. I hopI am not spamming the mailing list too much, but it's nice to get some degree of confirmation from those who know before I dive into something. so I gather now that actually I should leave the xf86SetCrtcForModes() alone, and just add setting the clock with CCR6C, CCR6D (and enabling it with CCR68). I'll see how that goes... bruno On Thu, 8 Mar 2007, bruno schwander wrote: On Thu, 8 Mar 2007, Alex Deucher wrote: The siliconmotion driver doesn't explicitly set the vclk pll. It uses the bios (if UseBIOS is set or does nothing if not). that is what I was wondering... well, if I do not Options UseBIOS false all I get is a blank screen. So I have to disable it. I did not realize that it did not set the pixel clock since when using a default VGA 640x480 resolution, it was working. So I guess it just happens to stay at whatever pixel clock the BIOS or console driver had set it to ? That seems very strange. It's trivial to add however. SR6C, SR6D are programmed similarly to the mclk. I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was really set. All this makes more sense now. So what you are saying is that in smi_driver.c : SMI_PreInit(), I should replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that programs vclk explicitely ? How can it set the crtc for several modes ? That is what xf86SetCrtcForModes() seems to do, right ? I still have a lot to learn. thanks for all the help guys, trudging along... bruno Alex Bruno On Wed, 7 Mar 2007, bruno schwander wrote: ah actually now it is not choosing my modeline and I do not understand why: (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz (II) Silicon MotionClock range: 14.00 to 135.00 MHz (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz (II) Silicon MotionNot using mode 640x480i (vrefresh out of range) (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz (II) Silicon MotionNot using default mode 640x350 (vrefresh out of range) vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz vrefresh, rejected ? the modeline is as follows: ModeLine 640x480i 24.44 640 680 728 776 480 480 484 525 Interlace Composite bruno On Wed, 7 Mar 2007, bruno schwander wrote: I think I figured it out, however it seems that although my modeline includes 'composite' DisplayModePtr mode-Flags V_CSYNC does not evaluate to true. I assume as long as the 'composite' keyword is found on the modeline, the flag should be set, right ? I need to add some debug messages, but this seems a little strange. Is there something else that needs to be configured, like telling that the driver actually supports the composite keyword on the modeline ? On a different note, the latest X release does not seem to work on that chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test this stuff. I figure XFree86 4.5 should work, but 4.6 does not. I'll provide patches to all and note on which version it was tested of course, once it works :-) bruno On Tue, 27 Feb 2007, Marc Aurele La France wrote: On Sun, 25 Feb 2007, bruno schwander wrote: On Fri, 23 Feb 2007, Marc Aurele La France wrote: On Thu, 22 Feb 2007, bruno schwander wrote: A little background: I have a single board PC with a SMI712 (lynxEM+) graphic chipset. X works like a charm. The driver currently ignores the V_CSYNC mode flag, so you would need to come up with a source patch to change that. I'd be happy to provide a patch, if I can figure where to put that. Since it is only a matter of setting one register it should be simple enough. I have (had?) no idea where to start, I'll grep for V_CSYNC and see... An appropriate spot for such changes would be after calls to vgaHWInit(), which, in this case, is in SMI_ModeInit(). Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http
incomplete docs ?
Hi all, I noticed some manpages and documentation is missing from the release information available at http://xfree86.org/current/RELNOTES4.html . Are these web pages automagically generated from the xfree86 sources ? bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Live Touchscreen Calibration [WAS: magictouch touch screen driver]
It would be great if you could add that... what do you mean by live calibration ? It seems to me that calibration should be (mostly) a userland utility, that you do not want to run everytime the Xserver starts. I probably misunderstood what you meant. My only issue currently, is that if resolution changes, the mapping from touchscreen coords to screen coords changes, thus the touchscreen driver should be able to be notified, or query what the actual screen resolution is. The trick mentioned previsously about querying the current modeline would work, but it's a hack... something cleaner (portable, etc.) would be nicer. I admit I do not know the specifics of touchpad/stylus support, but I imagine that is also the only dynamic/live resolution support that would be necessary ? Something like XFGetCurrentMonitorResolution(displayID, width, height) ... BTW, I submitted the source for the magictouch driver on this mailling list, is there any chance it will appear in the XFree86 tree someday ? If a comitter needs changes, fixes to it or has questions, I'll be happy to help as I can. bruno On Thu, 9 Jun 2005, Fred Gleason wrote: On Tuesday 07 June 2005 16:04, Tristan Van Berkom wrote: Since touchscreen drivers seem to be getting back in style, maybe we should write up some live calibration support ;-) I'm game. I've actually been toying with the idea of doing something like this for the ELO drivers for some time. Before I go charging off and reinventing the wheel, does anything simiklar to this exist already? Ideally, it should be sufficiently generic that any input device that uses absolute coordinates will be able to use it. Cheers! ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: magictouch touch screen driver
On Thu, 26 May 2005, Andrew C Aitchison wrote: On Wed, 25 May 2005, bruno schwander wrote: I tried using the screenInfo everytime the x,y position is scaled and returned, but that does not seem to help. I do not know how to support screen resolition changes. If anybody has an idea, let me know. This is a long shot. Clients like xdpyinfo use XF86VidModeGetModeLine() to get the video timings, which include the current screen resolution. I'm used to using this to see whether the resolution has been changed with CtrlAltNum+ and CtrlAltNum-. That sort of resolution change leaves you with a virtual desktop, so I don't know if it makes sense with a touch screen, but if so XF86VidModeGetModeLine *doesn't* report the viewing window, which makes the returned values less helpful. what would be useful is to find out the actual current screen resolution, not the virtual screen. Otherwise, the touchscreen behaves as if covering the whole virtual screen. I want just the visible screen. I don't think it would be useful to know what the viewing window is. I'll check on that modeline api, thanks. I am surprised this has not been solved in other drivers though. bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: magictouch touch screen driver
I tried using the screenInfo everytime the x,y position is scaled and
returned, but that does not seem to help. I do not know how to support
screen resolition changes. If anybody has an idea, let me know.
The driver is basically a slightly massaged dmc driver, there is probably
still some stuff to clean. Here it is as a shell archive (don't know it
the maillist rejects attachments...)
bruno
On Tue, 24 May 2005, David Dawes wrote:
On Tue, May 24, 2005 at 08:05:43AM -0700, bruno schwander wrote:
I have my driver for the serial MagicTouch touchscreen working. There is
just one thing that I am not sure of: if the resolution is changed
dynamically (by some program running fullscreen for example), the scaling
is off. How do I find if the resolution has changed ? Right now, I check
the screen size when the device inits, and store that away. Should I
instead use the actual screen size everytime through screenInfo ? Is that
safe ? Also, how can I twiddle the DTR, RTS lines, I do not find some
abstraction for that...
Maybe xf86SetSerialModemState() will let you twiddle the DTR, RTS lines.
I haven't looked at that stuff in a while. Perhaps someone else can give
you some answers to your other questions.
then, how do I submit the driver ? send it to this list ?
You can either send it here, or submit it at bugs.xfree86.org.
David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# magictouch
# magictouch/Imakefile
# magictouch/xf86MagicTouch.c
# magictouch/magictouch.man
# magictouch/xf86MagicTouch.h
#
echo c - magictouch
mkdir -p magictouch /dev/null 21
echo x - magictouch/Imakefile
sed 's/^X//' magictouch/Imakefile 'END-of-magictouch/Imakefile'
X#define IHaveModules
X#include Server.tmpl
X
XSRCS = xf86MagicTouch.c
XOBJS = xf86MagicTouch.o
X
XDRIVER = magictouch
X
XINCLUDES = -I. -I$(XF86COMSRC) -I$(XF86SRC)/loader -I$(XF86OSSRC) \
X -I$(SERVERSRC)/include -I$(XINCLUDESRC) -I$(EXTINCSRC)
X
X#if MakeHasPosixVariableSubstitutions
XSubdirLibraryRule($(OBJS))
X#endif
X
XModuleObjectRule()
X
XObjectModuleTarget($(DRIVER),$(OBJS))
X
XInstallObjectModule($(DRIVER),$(MODULEDIR),input)
X
X#if !defined(XF86DriverSDK)
XInstallModuleManPage($(DRIVER))
X#endif
X
XDependTarget()
X
XInstallDriverSDKObjectModule($(DRIVER),$(DRIVERSDKMODULEDIR),input)
END-of-magictouch/Imakefile
echo x - magictouch/xf86MagicTouch.c
sed 's/^X//' magictouch/xf86MagicTouch.c
'END-of-magictouch/xf86MagicTouch.c'
X/*
X * Copyright (c) 2005 Bruno Schwander
X * Author: Bruno Schwander [EMAIL PROTECTED]
X * Template driver used: dmc:
X *
X * Copyright (c) 1999 Machine Vision Holdings Incorporated
X * Author: Mayk Langer [EMAIL PROTECTED]
X *
X * Template driver used: Copyright (c) 1998 Metro Link Incorporated
X *
X * Permission is hereby granted, free of charge, to any person obtaining a
X * copy of this software and associated documentation files (the Software),
X * to deal in the Software without restriction, including without limitation
X * the rights to use, copy, modify, merge, publish, distribute, sublicense,
X * and/or sell copies of the Software, and to permit persons to whom the
X * Software is furnished to do so, subject to the following conditions:
X *
X * The above copyright notice and this permission notice shall be included in
X * all copies or substantial portions of the Software.
X *
X * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
X * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
X * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
X * THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
X * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
X * OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
X * SOFTWARE.
X *
X */
X
X#define _MGT_C_
X
X#include misc.h
X#include xf86.h
X#define NEED_XF86_TYPES
X#include xf86_ansic.h
X#include xf86_OSproc.h
X#include xf86Xinput.h
X#include xisb.h
X#include exevents.h
X
X#include xf86MagicTouch.h
X
XInputDriverRec MGT = {
X1,
Xmagictouch,
XNULL,
XMGTPreInit,
X/*MGTUnInit*/NULL,
XNULL,
X0
X};
X
X
X
X#ifdef XFree86LOADER
X
Xstatic XF86ModuleVersionInfo VersionRec =
X{
X magictouch,
X MODULEVENDORSTRING,
X MODINFOSTRING1,
X MODINFOSTRING2,
X XF86_VERSION_CURRENT,
X 1, 0, 0,
X ABI_CLASS_XINPUT,
X ABI_XINPUT_VERSION,
X MOD_CLASS_XINPUT,
X {0, 0, 0, 0}/* signature, to be patched
into the file by
X
Re: magictouch touch screen driver
I have my driver for the serial MagicTouch touchscreen working. There is just one thing that I am not sure of: if the resolution is changed dynamically (by some program running fullscreen for example), the scaling is off. How do I find if the resolution has changed ? Right now, I check the screen size when the device inits, and store that away. Should I instead use the actual screen size everytime through screenInfo ? Is that safe ? Also, how can I twiddle the DTR, RTS lines, I do not find some abstraction for that... then, how do I submit the driver ? send it to this list ? bruno On Sun, 22 May 2005 [EMAIL PROTECTED] wrote: Hi everybody, I am interested in getting the magictouch driver running. According to the cvs comments, it needs updating to the new 4.x interfaces. My questions are then: - Is there a sample/dummy input driver available ? The one I could find is marked as out of date. - If there is no good sample driver, which driver would be a good starting point ? i.e. up to date, not cluttered by extra device-specific stuff... I see dmc is still described in the driver man pages (thus probably functional?) so I was going to use that as a model, unless someone more familiar with XFree86 development sends me in another direction. Any advice, things to watch out for, are welcome... bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
