Detecting Monitor mode from AutoConfig
Title: Message Is there an interface available to enumerate the video modes supported by a monitor? It would be nice to get this information for use in auto config. We have a dual head configuration with one monitor which supports up to 1024 x 768 and the second up to 800 x 600. The problem is that X tries to drive the second monitor at 1024 x 768. If I configure XF86 manually I can get the first to run 1024 X 768 and the second in 800 x 600. I want to customize the monitor sections of auto config. I have already modified auto config to support multiply heads but now would like to implement custom monitor configurations. Any help or suggestions would be appreciated. Kirk Haderlie Design Engineer Vivid Image Technology [EMAIL PROTECTED]
Re: XAA bug
Mark Vojkovich wrote: Yes, it should be the dstPtr. I didn't know anyone used the Color8x8 pattern path. It's not an interesting path if you support Mono patterns. Well, months after I implemented acceleration for Color8x8 patterns I today for the first time succeeded triggering this. KDE (or Qt?) fills the background with a 2x2 pattern using this under some circumstances. I already commit the fix to the CVS. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA bug
Yes, it should be the dstPtr. I didn't know anyone used the
Color8x8 pattern path. It's not an interesting path if you
support Mono patterns.
Mark.
On Mon, 6 Oct 2003, Thomas Winischhofer wrote:
> In xaaPCache.c, lines 2051 and following, a Color8x8 pattern is written
> to the cache.
>
> Hm. This looks like this:
>
> /* Write and expand horizontally. */
> for (i = h, dstPtr = data, srcPtr = pPix->devPrivate.ptr; i--;
> srcPtr += pPix->devKind, dstPtr += pScrn->bitsPerPixel) {
> nw = w;
> memcpy(dstPtr, srcPtr, w * Bpp);
> while (nw != 8) {
> memcpy(dstPtr + (nw * Bpp), srcPtr, nw * Bpp);
> nw <<= 1; ^^
> }
> }
>
> That should read:
>
> /* Write and expand horizontally. */
> for (i = h, dstPtr = data, srcPtr = pPix->devPrivate.ptr; i--;
> srcPtr += pPix->devKind, dstPtr += pScrn->bitsPerPixel) {
> nw = w;
> memcpy(dstPtr, srcPtr, w * Bpp);
> while (nw != 8) {
> memcpy(dstPtr + (nw * Bpp), dstPtr, nw * Bpp);
> nw <<= 1; ^^
> }
> }
>
> IMHO, one can't expand the pattern from the SOURCE, but should use the
> DESTINATION instead.
>
> Everybody agree?
>
> Thomas
>
> --
> Thomas Winischhofer
> Vienna/Austria
> thomas AT winischhofer DOT net *** http://www.winischhofer.net/
> twini AT xfree86 DOT org
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 8500 with TFT/DVI uses 60Hz modes only
> Patrick Mau <[EMAIL PROTECTED]> wrote: > > > I'd really like to use modes above 60Hz for video playback. Maybe > > this is completly wrong, but to me it seems that video streams with > > 25fps have less "tearing" with 75Hz refresh rates. > > I doubt that you'll see improvements with more than 60 Hz on a TFT - > even with video playback. I ran quite a lot of different TFT's (analog > and DVI) on ATI Radeon7000/7500/9100 and to my experience you're best > with 60 Hz, > > Martin. That probably depends on the display, and maybe even the input you use. I have an SGI 1600SW, and it makes a huge difference whether I run it with 50 or 60 Hz when viewing video. I believe there are displays that convert everything to 60Hz, so YMMV. Rainer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XAA bug
In xaaPCache.c, lines 2051 and following, a Color8x8 pattern is written
to the cache.
Hm. This looks like this:
/* Write and expand horizontally. */
for (i = h, dstPtr = data, srcPtr = pPix->devPrivate.ptr; i--;
srcPtr += pPix->devKind, dstPtr += pScrn->bitsPerPixel) {
nw = w;
memcpy(dstPtr, srcPtr, w * Bpp);
while (nw != 8) {
memcpy(dstPtr + (nw * Bpp), srcPtr, nw * Bpp);
nw <<= 1; ^^
}
}
That should read:
/* Write and expand horizontally. */
for (i = h, dstPtr = data, srcPtr = pPix->devPrivate.ptr; i--;
srcPtr += pPix->devKind, dstPtr += pScrn->bitsPerPixel) {
nw = w;
memcpy(dstPtr, srcPtr, w * Bpp);
while (nw != 8) {
memcpy(dstPtr + (nw * Bpp), dstPtr, nw * Bpp);
nw <<= 1; ^^
}
}
IMHO, one can't expand the pattern from the SOURCE, but should use the
DESTINATION instead.
Everybody agree?
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net/
twini AT xfree86 DOT org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
RE: Starting XFree86 without an XF86Config file
>Fortunately XF86VidModeSetGammaRamp() and friends allow these values >to be altered by any application while the server continues to run. >This means that a configuration program can write the data to a file, >then have a simple user-mode app run as part of the start-up script >which reads the data and passes it to the server via >XF86VidModeSetGammaRamp(). > >No need for this data to reside in a root-owned X server config file. That is a help, but it doesn't totally solve the problem. At the beginning of the thread we were talking about the need for run-time and init-time configuration. I wasn't aware of this XF86VidModeSetGammaRamp() function but it seems it is the opposite of the other problems that were discussed. It _has_ run-time configuration but no init-time configuration. If an external tool is used, it will only solve the problem for some of the cases. Set-top-boxes need to display a splash screen asap, and nothing else until they are fully initialized. If the splash screen comes up before we are ready to accept clients then we can't have the correct gamma on the splash screen... It isn't so much of a problem that the gamma is slightly off, but that it will change while on-screen. Lets not get into the details of solving the gamma issue, given any single problem a solution could be worked out. The specifics aren't important. XFree currently has some init-time configurable parameters and some run-time configurable parameters. It would be a good plan to make any new configuration system/tool solve the init-time and run-time problems for all parameters. -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xinput Q: SometimesCore possible ?
While doing some much-needed cleanup work on my calcomp Xinput driver, i have coded myself into a corner where i would need to switch CorePointer capability on and off depending on the current tablet coordinates. As far as i can tell, the current Xinput framework always sends both Core and Extension events when in CorePointer mode, and registers CorePointer capability on module startup only. What i would like to do is have the central area of the tablet act as a CorePointer, while its surroundings report Extension events only. I think i have solved this for the MotionEvents (by a specially tailored ConvertProc), but i do not see how to filter ButtonEvents in a similar way. Currently, button events in the outer, none-core region are reported both as the extension events i want, and as core events occuring at the last valid cursor position on the screen. I have tried to set/unset the XI86_ALWAYS_CORE flag in my driver module depending on the coordinates, but this does not seem to have any effect. Is anything like this possible at all ? TIA, Martin -- Dr. Martin Kroeker, daveg gmbh Darmstadt CAD/CAM/CAQ [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: USB Multimedia Keyboards. Some keys do not produce keyevents.
Hi, > > If that module doesn't know how to emulate a scn-code for some key it > > prints this message (note it is not Xserver's message but kernels one) and > > passes nothing. In such case there is nothing to read for Xserver and you > > don't see any events in xev. > > However, showkey -s does show the scan codes, so is the kernel not passing it > along anyway? Maybe I'm not understanding the whole process, but I thought > that it still passes the scan code on if it doesn't know what to do with it. It is strange. As far as I know 'showkeys -s' uses the way of getting scan-codes the same as Xserver uses. I have not such keyboard and can't test it. Could you give an example of such keys? What codes showkeys shows? Do you confirm that for the same key showkeys outputs some code without any kernel messages but xev shows nothing and the kernel message you wrote about appears somewhere? -- 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
KDrive and Elo touchscreen
Hi, I am developing an embedded application, in which I want to use KDrive. My application uses a Elographics Touchscreen, which is supported by the normal X server, but, as far as I know it is not supported by KDrive (am I right?). If so, could anyone give me a hint on how to hack KDrive to support my touchscreen? Thanks in advance, -- Carlos Mateo [EMAIL PROTECTED] --- Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 8500 with TFT/DVI uses 60Hz modes only
Patrick Mau <[EMAIL PROTECTED]> wrote: > I'd really like to use modes above 60Hz for video playback. Maybe > this is completly wrong, but to me it seems that video streams with > 25fps have less "tearing" with 75Hz refresh rates. I doubt that you'll see improvements with more than 60 Hz on a TFT - even with video playback. I ran quite a lot of different TFT's (analog and DVI) on ATI Radeon7000/7500/9100 and to my experience you're best with 60 Hz, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Memory Allocation Problems for Intel 845G
On Fri, 2003-10-03 at 14:31, Daniel Stone wrote: > On Thu, Oct 02, 2003 at 06:33:52AM -0700, Alex Deucher wrote: > > you or christian should add this as a bug to bugzilla > > (http://bugs.xfree86.org/). This is the new method for posting patches > > to be accepted into cvs. > > This isn't a patch to be accepted into CVS, only an idea; as it stands, it's an > external binary. Its main function is to show one what registers need what data > shoved in to them. Perhaps the i810 maintainer could have a look? I certainly don't have the knowledge to apply the patch to CVS. -- ~~ Using Linux on the Inspiron 1100: http://geocities.com/randomnumbergenerator2001/ *regularly updated* ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
