<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<pre>I'm not quiet understand what you are speaking and if it can solve the <br>problem list in this mail. Highly expect 1.3 have this feature.<br><br>Thanks a lot!<br> <br><br>Le lundi 04 juin 2007 à 22:52 -0400, Meng Tang a écrit :<br>> Hi All,<br>> <br>> Any could help me to fix a problem of change the resolution of X and <br>> touchscreen?<br>> I have fedora 6 installed, a touchscreen which compatible to<br>> elographics(use <br>> driver elographics_drv.so)<br>> Problem is,<br>> 1. If I start X wiith 640x480, the touchscreen is fine.<br>> 2. If I start X with 800x600, the touchscreen is fine also.<br>> 3. If I change the X resolution by xrandr, from 800x600 to 640x480,<br>> the <br>> resolution of touchsceen don't change. The pointer will leave my<br>> finger a <br>> distance. Distance increase when I move my finger to right and bottom.<br>> 4. I have tried to change the resolution by ctrl - +/-, but the<br>> problem is <br>> same there.<br> <br>yep, this is "normal". You will probably hit the same problem if you<br>want to rotate your screen. I've tried to get feedback on what to do on<br>the ml, but it seems the answer is only, do it on client side (ie.<br>script it to do all you need to do to rotate or resize).<br>-- <br>Gilles Dartiguelongue <dartigug@esiee.fr><br> </pre><br><br>> Subject: RandR 1.3 additions?<br>> From: keithp@keithp.com<br>> To: xorg@lists.freedesktop.org<br>> Date: Fri, 13 Jul 2007 11:32:28 -0700<br>> <br>> So, if you're monitoring the xorg-commit list, you will have seen an<br>> addition to RandR float by. I think we should consider what stuff should<br>> be in a 1.3 version of RandR at this point; we have several good<br>> suggestions:<br>> <br>>      1. DPMS events. This is what Eric added in his randr-dpms branch.<br>>         This adds an event delivered when an output changes DPMS status,<br>>         allowing applications to detect when the screen is blanked for<br>>         any reason.<br>>      2. Per-output DPMS set/get. Right now, DPMS setting is global.<br>>         Allowing applications to set DPMS levels individually for each<br>>         output would provide some useful functionality.<br>>      3. Panning rectangle. RandR 1.2 drops the old built-in panning<br>>         functionality as you rarely want your extended-mode monitors to<br>>         all follow the mouse around the virtual desktop. If we, instead,<br>>         allowed each crtc to automatically pan within a limited<br>>         rectangle, we would be able to use panning again in a way<br>>         consistent with RandR. The Xinerama information provided to<br>>         applications would then mark the set of panning rectangles<br>>         instead of the set of crtc mode rectangles.<br>> <br>> Are there other things we should consider adding to the RandR protocol<br>> at this point?<br>> <br>> -- <br>> keith.packard@intel.com<br><br /><hr />Connect to the next generation of MSN Messenger   <a href='http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline' target='_new'>Get it now! </a></body>
</html>