Tochscreen calibration with xDeviceTSCalibrationCtl
Hi, i wanted to write a little calibration app for a touchscreen-driver. So, i looked on the source and found the control_proc function on many touch-drivers. This function can receive a xDeviceCtl, if i understand right. The 'xDeviceCtl' is the casted to 'xDeviceTSCalibrationCtl' (e.g. in DMC driver, but also in many othe drivers). I think this is the right way to calibrate or i'am wrong? So wanted to access the control_proc function from the app with 'XChangeDeviceControl(display, device, control, value)'. But the only controll which is supported is 'DEVICE_RESOLUTION' with his struct 'XDeviceResolutionControl'. A simple cast doesn't work. How i can transmit the 'xDeviceTSCalibrationCtl' or is this imposible at present? Is there another conventional way for calibration? Thank you for help. regards Stefan ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tochscreen calibration with xDeviceTSCalibrationCtl
I am far from knowledgable on XFree, but for a laptop a friend of mine wrote a calibration tool that had the same problems. The problem was 'solved' by writing the changes in XF86Config and restarting X. An idea I heard here a week ago was to let the driver open a different file (a device or a special made file for the purpose) and check if it has been written to just like (for example) is done with the serial port. Its ugly; but if it works, you don't hear me complaining. When you find a good solution, please share it with us, I'm quite interrested. On Sun, Feb 23, 2003 at 06:01:24PM +0100, Stefan Warmuth wrote: Hi, i wanted to write a little calibration app for a touchscreen-driver. So, i looked on the source and found the control_proc function on many touch-drivers. This function can receive a xDeviceCtl, if i understand right. The 'xDeviceCtl' is the casted to 'xDeviceTSCalibrationCtl' (e.g. in DMC driver, but also in many othe drivers). I think this is the right way to calibrate or i'am wrong? So wanted to access the control_proc function from the app with 'XChangeDeviceControl(display, device, control, value)'. But the only controll which is supported is 'DEVICE_RESOLUTION' with his struct 'XDeviceResolutionControl'. A simple cast doesn't work. How i can transmit the 'xDeviceTSCalibrationCtl' or is this imposible at present? Is there another conventional way for calibration? Thank you for help. regards Stefan -- Thomas Zander ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XVideo bug report with an i845G
On Sat, Feb 22, 2003 at 02:33:38PM -0600, Billy Biggs wrote: A user of one of my apps reported this in a bug report. My app outputs to a 4:2:2 Y'CbCr surface (YUY2) using XVideo at a high framerate: I tried resizing the window and all is well ... until when the window gets smaller and smaller. Then BAM! X freezes with a blank screen. Nothing else works except a reboot. By the way, I have a P4 system with a Intel-845G chipset. I just upgraded to XFree86 4.2.99 beta, so the above maybe the problem. Hope someone finds this information useful, Can you give me an exampe of an XVideo app that demonstrates this problem? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Driver for CVS?
On Sat, Feb 22, 2003 at 10:15:59PM +0100, Thomas Zander wrote: Hi, I have been finetuning a driver for the paceblade touchscreen for a long time now; and it has been publicaly available in the pacebook CVS (on sourceforge). I feel that the only proper place to place this driver is in the XFree CVS. Is it possible that I get an CVS account so I can place and maintain the driver in the XFree CVS tree? XFree86 commit access isn't given out like this. Please feel free to submit your driver to XFree86 (via [EMAIL PROTECTED]) after 4.3. Would be super if that can happen before 4.3; with the argument that a new driver is hardly going to break other stuff :) I can see the appeal of that argument, but my experience with XFree86 releases tells me otherwise. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Driver for CVS?
On Sun, Feb 23, 2003 at 07:22:02PM +0100, Thomas Zander wrote: On Sun, Feb 23, 2003 at 01:00:23PM -0500, David Dawes wrote: On Sat, Feb 22, 2003 at 10:15:59PM +0100, Thomas Zander wrote: Hi, I have been finetuning a driver for the paceblade touchscreen for a long time now; and it has been publicaly available in the pacebook CVS (on sourceforge). I feel that the only proper place to place this driver is in the XFree CVS. Is it possible that I get an CVS account so I can place and maintain the driver in the XFree CVS tree? XFree86 commit access isn't given out like this. Please feel free to submit your driver to XFree86 (via [EMAIL PROTECTED]) after 4.3. Does that mean the code I submit can not be changed by me without sending a diff to the fixes email? Yes, that's correct. Who is the one that decides to add features and code changes then? In other words; who is responsible for that driver (and incidently, for all drivers in CVS). There's no equivalence between maintaining a driver and committing its changes to the XFree86 CVS repository. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Driver for CVS?
On Sun, Feb 23, 2003 at 01:46:37PM -0500, David Dawes wrote: On Sun, Feb 23, 2003 at 07:22:02PM +0100, Thomas Zander wrote: On Sun, Feb 23, 2003 at 01:00:23PM -0500, David Dawes wrote: On Sat, Feb 22, 2003 at 10:15:59PM +0100, Thomas Zander wrote: Hi, I have been finetuning a driver for the paceblade touchscreen for a long time now; and it has been publicaly available in the pacebook CVS (on sourceforge). I feel that the only proper place to place this driver is in the XFree CVS. Is it possible that I get an CVS account so I can place and maintain the driver in the XFree CVS tree? XFree86 commit access isn't given out like this. Please feel free to submit your driver to XFree86 (via [EMAIL PROTECTED]) after 4.3. Does that mean the code I submit can not be changed by me without sending a diff to the fixes email? Yes, that's correct. Why the extra step? It poses an extra boundry for the developer that I don't like to work with. I can't work without CVS, committing for each small change so I get the advantages CVS was meant to have. Going back to a former version if I made too many changes that I don't like. Not possible without being able to commit a dozen times an hour. Who is the one that decides to add features and code changes then? In other words; who is responsible for that driver (and incidently, for all drivers in CVS). There's no equivalence between maintaining a driver and committing its changes to the XFree86 CVS repository. Just for my perception; how is the maintainer suppost to see which features are added, and by whom. Sending an email to fixes means the original authors name will not be in CVS.. Why this burdon on the developers and I think being a maintainer is not very easy either.. You are aware of the concept of cvs-acl, right? -- Thomas Zander ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Driver for CVS?
On Sun, Feb 23, 2003 at 02:30:15PM -0500, David Dawes wrote: On Sun, Feb 23, 2003 at 08:00:06PM +0100, Thomas Zander wrote: Why this burdon on the developers and I think being a maintainer is not very easy either.. There are many different development models, and everyone has their own view on which are better than others. Thats only natural; and I certainly don't have a problem with a different view on things. But with your answers I can never understand your way of working; my queries for the reasoning behind many of the things I see are negative compared to 'other' methods have not been answered. I'm just trying to find arguments of why you do the things you do, please don't feel like I am putting you down.. I feel xfree can use some of the advances in several different technologies, but with the limits imposed by the 'fixes' email address that will not happen, people will not try to create changes they are not quite sure will be committed. -- Thomas Zander ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On 22 Feb 2003, Jeff Brubaker wrote: No problem. It's possible the option you used worked around the problem. I found the true problem yesterday though (whew). ;o) Heh.. I spoke too soon yesterday. When I tried the new packages, I merely restarted XFree86. Today, the machine locked after a full reboot. It works with ForceInit, but not without, even with the newer packages. Sorry for the confusion. Hmm, weird. Dunno what to say about that one. I unfortunately do not have any savage hardware personally, and don't have specs for that chip either, so I'm not too sure what I'll be able to do to diagnose/debug any problems. All I've been doing is auditing driver changes over time and reverting suspects. It might be something that the driver maintainer (Tim) might have to investigate, however keep in mind that he is busy right now with other things I understand and might not be able to look into it right away. The more user feedback we all get from users with problems though, perhaps someone can determine problems and propose a fix. There's one issue I know of where 24bit depth doesn't work properly. Whoa, deja vu. After you mentioning DPMS on DFP, I decided to have a look at the DPMS code in the radeon driver, and the R200 specs. I just implemented DPMS on Radeon yesterday for DFP/LCD, but also noted the existing DPMS code looks a bit more complex than it needs to be, so I'm going to take a stab at rewriting Radeon DPMS support after 4.3.0 is out, using the documented DISP_PWR_MAN_DPMS instead of the current mechanism. The patch above is similar to what I've written, but still incomplete. I've had several people test my latest Radeon driver out with DPMS on CRT alone, LCD alone, DFP alone, and combination of CRT+LCD and CRT+DFP, but not on dual DFP (they're more rare). I'll probably send my DPMS patch in for potential 4.3.0 inclusion, but if it doesn't get in, then it's on my ftpsite for those interested. Sweet. Looking forward to it. The patch works great for several people with a variety of different display combinations, however I've had a bug report now from someone using just a CRT where DPMS causes the monitor to go into and out of suspend over and over. That sucks because the changes I added didn't touch the CRT path. I've decided in the interest of not causing regression to disable my patch until I can investigate things more closely, so I am not going to submit it for 4.3.0 inclusion at this stage. Perhaps it can be included in the 4.3 stable branch post 4.3.0 once I've had time to work the kinks out though. ;o/ -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
driver developer docs for RENDER extension
Hi, I am considering implementing the RENDER extension in a driver I am working on, and was wondering if there were any docs along the lines of the XAA.HOWTO that covers what the extension requires of me for each function I implement ... I have looked at the source in mga_storm.c and also at the info at eax.com and Keith's developers guide to XRender, but am not much the wiser. [While I'm sure I could work through it without such a thing, if there were something out there, it sure would help ...] BTW, if there's not, if someone could perhaps let me know what the hardware needs to be able to do to make implementing the extension worthwhile, it would at least allow me to make a decision as to whether or not it's even possible for me to implement, prior to doing any more research on it. thanks, -- Chris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon driver hides cursor over XVideo windows?
Which application was used ? best Vladimir Dergachev On Sun, 23 Feb 2003, Billy Biggs wrote: I've got a report that the radeon driver hides cursors after an inactivity timeout when above an XVideo window. Can anyone confirm or deny that? I think this is a bad idea and should be left up to the application for when to hide the cursor, especially for those which deal with menus (DVD apps, my OSD, ...). Seems like something that shouldn't be done in a driver. -- Billy Biggs [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon driver hides cursor over XVideo windows?
Vladimir Dergachev ([EMAIL PROTECTED]): Which application was used ? Ok nevermind, the user now wants me to say that he is an idiot. Sorry for wasting your time, -Billy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
