Re: [Xpert]2 Mice one default - feature request
jg <[EMAIL PROTECTED]> writes: > I am very surprised it is not possible to specify a Default > configuration. >From the man-page: | A ServerLayout section is considered "active" if it is referenced by | the -layout command line option. If that option is not used, the | first ServerLayout section found in the config file is considered | the active one. So what exactly do you want to do that cannot reasonably be done with what is already there? Thomas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X server dies when I call Xv[Shm]PutImage()
Mark Vojkovich ([EMAIL PROTECTED]): > On Mon, 4 Feb 2002, Steve Kirkendall wrote: > > I'd be surprised if a voodoo card could do 2048x2048. It's one of the > worst overlay hardware. Doesn't seem to do the correct YUV->RGB > colorspace conversion either (ie. not CCIR601). Arguably we shouldn't be using the 601 transfer functions anyway, we should use the ITU-R BT.709 ones instead since CRTs are likely closer to the HDTV standard. I'd also add that MPEG2 video actually specifies the 709 transfer function (those mmx'ified yuv2rgb routines everywhere are usually doing the outdated transfer). Do you know what conversion they are using? > > the smoothing seems to kick in at 1024x768. This is true for DVD > > player programs too, not just my XMMS plugin. But is there some way > > I can detect this? DVDs look better when played with filtering in a > > 1024x768 screen than they do unfiltered in a 1600x1200 screen. > > There's no way to detect that. Ideally, DVD's would look best at > 720x480 without scaling. Where best is defined as stretchy. 720x480 at 4:3 or 16:9 isn't square pixel so unless you're lucky you always need to scale. :) For best as in least artifacts due to bilinear filtering of gamma corrected images in nonlinear space I'd have to agree with you also. :) -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X server dies when I call Xv[Shm]PutImage()
On Mon, 4 Feb 2002, Steve Kirkendall wrote: > I wrote an XMMS visualization plugin called Blursk a couple of years ago. > Now I'm trying to add support for full-screen output via XVideo, with mixed > success. > > First the details: I'm running XFree86 4.1.0 under SuSE Linux 7.3. My > video card is a Voodoo3/3000 AGP. I normally run it at a resolution of > 1600x1200, 16bpp. > > The good news is, I can now display a 400x300 image full-screen. I can > even display it on the root window, like animated wallpaper. The speed is > good -- about as fast as in a window. It looks pretty damn cool. > > The bad news is, there are some quirks. The biggest and scariest is that > the X server dies if I try some image sizes. There doesn't seem to be > any pattern to it. Odd, even, larger, smaller, same aspect ratio, wide > aspect ratio... They all stand a good chance of killing the server. By > strategically adding XSync() calls and fprintf() calls to the code, I've > been able to determine that it is dying while processing an XvPutImage() > or XvShmPutImage() request. (The use of shared memory apparently makes > no difference.) > > This has to be a bug in the X server, XVideo extension, or TDFX driver. > There's no way a client should be able to kill the server. But DVD > player software is able to use 720x480 images without trouble, so there > must be something I'm doing that's weird. > > I'm appending my alloc_image() function, below. The rest of the > initialization code doesn't care about the image size, so I don't think > it can be faulty. And the Xv[Shm]PutImage() calls are too simple to have > any bugs this subtle in them, so I'm pretty sure there must be something > wrong in the image allocation. The X-server should never crash. It's probably a problem in the driver though, since I've not seen problems like you describe on other hardware. > > The image format is always packed YUV, 16 bits per pixel, in YUYV order. > If that matters. I wouldn't be surprised to learn that DVD players used > a planar layout, or something like that. They usually use planar. > > Other issues include: > > * Although "xvinfo" reports a maximum image size of 2048x2048, the width >is actually limited to 1024. I haven't stress tested the height. The >width thing is actually a little weird -- if I request a 1280x480 >image buffer, it doesn't fail; it just gives me a 1024x480 image buffer. >Is this normal? In the code, the driver is obviously advertising 2048x2048 and yet clamping all sizes to 1024x1024. One of those is in error. I'd be surprised if a voodoo card could do 2048x2048. It's one of the worst overlay hardware. Doesn't seem to do the correct YUV->RGB colorspace conversion either (ie. not CCIR601). > > * Filtering (to smooth out the enlarged pixels) is not performed when >I'm running the display at my usual resolution of 1600x1200. If I >switch resolutions via and , Hardware limitations. 3dfx hardware can't scale in "2x" mode if I remember correctly. >the smoothing seems to kick in at 1024x768. This is true for DVD >player programs too, not just my XMMS plugin. But is there some way >I can detect this? DVDs look better when played with filtering in a >1024x768 screen than they do unfiltered in a 1600x1200 screen. There's no way to detect that. Ideally, DVD's would look best at 720x480 without scaling. > > * By the way, is this extension officially called "XVideo" or "Xv"? It >seems to be listed both ways, in different places. Not clear exactly. The extension string says XVideo, but even DEC's original docs usually refer to it as Xv. > > * I've noticed that, on my Voodoo3 at least, XVideo uses color #f8 >as a mask color. This is pretty cool, because if I run Blursk in the >root window, I can then use color #f8 to let the Blursk animation >shine through. For example, "xterm -fg white -bg '#f8'" gives me >an xterm with a transparent background. Is this standard? Does XVideo >always use color #f8 for this? If the color varies, how can I find >out what it is? Blursk users might have fun with this. A color key is standard on overlay adaptors. Not only can you query it but you can change it programatically. There is a standard XV_COLORKEY port attribute which you can query and set. If the attribute doesn't exist or is marked read-only, you can't change it. See xc/doc/hardcopy/Xv/video in the server tree on querying attributes. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Radeon VE dual-headed problems
I'm having trouble using both outputs on my Radeon VE: The second Radeon device never prints anything, and the monitor on the dvi port receives no signal. I also notice that the first screen listed in the ServerLayout section ends up on the vga port, regardless of screen numbers in either the ServerLayout or Device sections. I'm using the current XFree86 as of 1/26/02 on FreeBSD 4.4. I'm enclosing my boot log and XF85Config file (I apologize for the length of the Monitor sections). I would be grateful for any help if this is a configuration problem. thanks, Jason <#part type="application/octet-stream" filename="~/two-headed-monster.log" disposition=attachment description="boot log"> <#/part> <#part type="text/plain" buffer=XF86Config.raw disposition=attachment description=XF86Config> <#/part> ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: User-level Tasks in Hotplug Scripts?
> Fundamentally, we have no convention right now for any client (root or not) > to connect to an X server except on initiation of the user (unless > the user is silly enough to disable authentication entirely. No single convention, no. And I don't know what's current, but I've certainly worked with systems where X11 desktop frameworks have one application registered in a network naming system, acting as an authorized intermediary for other clients. The other clients weren't allowed to directly contact users' X11 servers, but that intermediary either implemented or forked off components that _could_ do so. Who has a good summary of what current versions of Gnome and KDE do along those lines -- anything? I see /tmp/orbit-* files on my current Linux system, UNIX domain sockets rather than TCP ones. That makes me suspect at least Gnome doesn't yet have a widely interoperable solution of this type. > Certainly, I want no user intervention as much of the time as possible, but > also need a hotplug design which allows for user intervention at the > time of first use in cases where it may be necessary. The hotplug script > design needs to allow for this, even if it is not the usual case. I think it clearly does, though implementation is lacking. None of these problems is novel, all have been solved repeatedly by groups who've implemented desktop frameworks under X11. The transport choice gets political though: everyone has their favorite RPC-du-jour (often wagged by significant infrastructure tails). If there's no single standard yet, having the X session startup save a /var/run file with some daemon's transport address understood by the hotplug framework would suffice. For non-desktop systems, it could point to a remote sysadmin agent. The requests delivered there would not necessarily correspond to hotplug events. > And there is need to automatically run GUI based programs, even after > configuration (automatically downloading images off your camera, for > example). That's one of my canonical examples. Though when it's a webcam, not a still image camera, "downloading" means firing up the user's preferred video tool ... :) - Dave ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
On Tue, 5 Feb 2002, Oliver Neukum wrote: > > > > > Jim, if the user is logged in so is the rest of the user interface. Why > > not have a monitoring program (like console) that watches the hotplug > > events and invokes corresponding configuration program ? This would also > > allow for various user environments to customize configuration tools to > > match their look. > > That solution is not in itself sufficient. You might not want everybody > to see all hotplug events. I think it is. It is not very hard to to setup permission policy.. For example you can only allow this to users who are able to login at the console and not remotely. (By using GiveConsole/TakeConsole for xdm/kdm/gdm for example). I am sure you can get by with usual permissions based fifo in most if not all situations. However it is not difficult to devise a way more generic scheme than would ever be useful.. Say: have /var/hotplug/fifo/classX be fifos for different classes of events. Have /sbin/hotplug filter incoming events and echo them into these fifos. Have these fifos only accessible by root (or whatever /sbin/hotplug runs under). Write a simple daemon that monitors classX fifos and also /var/hotplug/fifo/command and passes the events onto a Unix socket on localhost.. make it named if like :) /var/hotplug/events for example. So, GiveConsole determines whether the user deserves access to classX events and if yes echo something like this: give_access classX 'xserver full displayname' A45GF_md5_random into command fifo and sets "CLASSX_ACCESS_CODE" property on the root window to A45GF_md5_random (with X being replaced by the class number). The monitor app reads off these codes and passes them the daemon which then uses them to actually enable passthru of messages. When the server closes the root window gets destroyed and TakeConsole echos the following: revoke_access 'xserver full displayname' to allow the daemon to discard codes that will no longer be used. So, here, it was long and overcomplicated but I don't see how you may want something more flexible than this. Vladimir Dergachev > > Regards > Oliver > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
> >>Jim, if the user is logged in so is the rest of the user interface. Why > >>not have a monitoring program (like console) that watches the hotplug > >>events and invokes corresponding configuration program ? Actually one of the goals of the hotplug framework is to avoid requirements to have Yet Another Monitoring Daemon hanging around wasting resources ... likewise, to avoid needing to start the apropriate magic program before plugging in devices. > >>This would also > >>allow for various user environments to customize configuration tools to > >>match their look. ... of course, if the events could get fed into some existing daemon (via authenticared RPC, SSH-secured channel, or whatever) that kind of appearance-agnostic behavior becomes simpler! The issue then becomes how hotplug identifes and accesses the channel, and who will modify what existing daemons. :) > > That solution is not in itself sufficient. You might not want everybody > > to see all hotplug events. > > And what would the problem be with using an event distribution mechanism > that would require the listener to have certain privileges? Another of the goals classic end-user "usability". Remember that the original problem was how to fire up an unprivileged tool ... not all hotplug events imply any need for privilege. Users initiate hotplug events with just physical access privileges. When the device software has already been set up, additional privilege shouldn't be needed. - Dave ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
> > Actually one of the goals of the hotplug framework is to avoid > > requirements to have Yet Another Monitoring Daemon hanging > > around wasting resources ... likewise, to avoid needing to start the > > apropriate magic program before plugging in devices. > > I wouldn't call using a few K's of memory a waste of resources. Most examples I've seen start at closer to an M or two, which does matter. I'd call such issues workable, though obesity in GUI frameworks has sometimes reached criminal levels. Re access rights: > Practically all desktop Linux distributions associates these kind of > things with console ownership. If you're on the console, you are allowed > access the graphics adapter, audio, floppy, cdrom, etc. devices. I don't > see a problem with hotplug management following the same scheme. Right, though it's not quite that simple even there. The "single user desktop" model is well known to be the one which is relatively straightforward to address -- and arguably hits the "95% of end users" case here. So long as one can kick in a "no gui" mode for servers, and do something intelligent in the case of multi-gui systems, that's a good place to start. - Dave ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]X server dies when I call Xv[Shm]PutImage()
I wrote an XMMS visualization plugin called Blursk a couple of years ago.
Now I'm trying to add support for full-screen output via XVideo, with mixed
success.
First the details: I'm running XFree86 4.1.0 under SuSE Linux 7.3. My
video card is a Voodoo3/3000 AGP. I normally run it at a resolution of
1600x1200, 16bpp.
The good news is, I can now display a 400x300 image full-screen. I can
even display it on the root window, like animated wallpaper. The speed is
good -- about as fast as in a window. It looks pretty damn cool.
The bad news is, there are some quirks. The biggest and scariest is that
the X server dies if I try some image sizes. There doesn't seem to be
any pattern to it. Odd, even, larger, smaller, same aspect ratio, wide
aspect ratio... They all stand a good chance of killing the server. By
strategically adding XSync() calls and fprintf() calls to the code, I've
been able to determine that it is dying while processing an XvPutImage()
or XvShmPutImage() request. (The use of shared memory apparently makes
no difference.)
This has to be a bug in the X server, XVideo extension, or TDFX driver.
There's no way a client should be able to kill the server. But DVD
player software is able to use 720x480 images without trouble, so there
must be something I'm doing that's weird.
I'm appending my alloc_image() function, below. The rest of the
initialization code doesn't care about the image size, so I don't think
it can be faulty. And the Xv[Shm]PutImage() calls are too simple to have
any bugs this subtle in them, so I'm pretty sure there must be something
wrong in the image allocation.
The image format is always packed YUV, 16 bits per pixel, in YUYV order.
If that matters. I wouldn't be surprised to learn that DVD players used
a planar layout, or something like that.
Other issues include:
* Although "xvinfo" reports a maximum image size of 2048x2048, the width
is actually limited to 1024. I haven't stress tested the height. The
width thing is actually a little weird -- if I request a 1280x480
image buffer, it doesn't fail; it just gives me a 1024x480 image buffer.
Is this normal?
* Filtering (to smooth out the enlarged pixels) is not performed when
I'm running the display at my usual resolution of 1600x1200. If I
switch resolutions via and ,
the smoothing seems to kick in at 1024x768. This is true for DVD
player programs too, not just my XMMS plugin. But is there some way
I can detect this? DVDs look better when played with filtering in a
1024x768 screen than they do unfiltered in a 1600x1200 screen.
* By the way, is this extension officially called "XVideo" or "Xv"? It
seems to be listed both ways, in different places.
* I've noticed that, on my Voodoo3 at least, XVideo uses color #f8
as a mask color. This is pretty cool, because if I run Blursk in the
root window, I can then use color #f8 to let the Blursk animation
shine through. For example, "xterm -fg white -bg '#f8'" gives me
an xterm with a transparent background. Is this standard? Does XVideo
always use color #f8 for this? If the color varies, how can I find
out what it is? Blursk users might have fun with this.
I should probably point out that my Voodoo3 card has been acting slightly
weird since I replaced my motherboard a few months ago. 3D acceleration
still works, but it is slower than it used to be. It seems to work fine
under Windows, but I don't use Windows enough to say that with confidence.
/* Allocate an XV image buffer */
static xvimg_t *alloc_image(int width, int height)
{
xvimg_t*img;
/* Allocate the xvImg struct */
img = (xvimg_t *)malloc(sizeof(xvimg_t));
/* shared memory is different from local memory */
if (xvOptShm)
{
img->mImage = XvShmCreateImage(xvDisplay, xvPort, xvFmtInfo.id,
0, width, height, &img->mShminfo);
if (!img->mImage)
{
about_error("Could not allocate shared memory image\n"
"You probably won't be able to use XV with shared memory,\n"
"but you might get it to work if you disable shared memory\n"
"via Blursk's [Advanced] dialog. Perhaps updating your\n"
"X server or libraries would help.\n");
free(img);
return NULL;
}
if (img->mImage->width != width || img->mImage->height != height)
{
about_error("Tried to allocate %dx%d image, but got %dx%d\n"
"XVideo usually has a limit on how large an image it can\n"
"handle. Sometimes the limit is smaller than the size\n"
"reported by xvinfo. Try reducing the size of your Blursk\n"
"window. If you're using \"XV doubled\", try switching to\n"
"plain \"XV\".",
width, height,
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
David Brownell wrote: > > Actually one of the goals of the hotplug framework is to avoid > requirements to have Yet Another Monitoring Daemon hanging > around wasting resources ... likewise, to avoid needing to start the > apropriate magic program before plugging in devices. > I wouldn't call using a few K's of memory a waste of resources. The program does of course not necessarily has to be started explicitly by the user. It would be added to whatever "autostart" mechanism the user interface in question would use. >>> >>And what would the problem be with using an event distribution mechanism >>that would require the listener to have certain privileges? >> > > Another of the goals classic end-user "usability". Remember that > the original problem was how to fire up an unprivileged tool ... not > all hotplug events imply any need for privilege. Users initiate hotplug > events with just physical access privileges. When the device software > has already been set up, additional privilege shouldn't be needed. > Practically all desktop Linux distributions associates these kind of things with console ownership. If you're on the console, you are allowed access the graphics adapter, audio, floppy, cdrom, etc. devices. I don't see a problem with hotplug management following the same scheme. In fact , it _should_ follow the same scheme - wouldn't it be quite stupid if you could manage hot plug devices, but not access the floppy or cdrom?? Or does this concept have to change, too? -- Christer Palm ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
Oliver Neukum wrote: >>Jim, if the user is logged in so is the rest of the user interface. Why >>not have a monitoring program (like console) that watches the hotplug >>events and invokes corresponding configuration program ? This would also >>allow for various user environments to customize configuration tools to >>match their look. >> > > That solution is not in itself sufficient. You might not want everybody > to see all hotplug events. > And what would the problem be with using an event distribution mechanism that would require the listener to have certain privileges? -- Christer Palm ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A question about: Xv driver, xserver and kde or gnome
On Mon, 4 Feb 2002, hzeng wrote: > Hi, > The question has troubled me very long. I don't know the where is the trouble. >In my thought,Xv driver belong to the > DDX layer of Xserver, and kde or gnome are the app(window manager) build upon >Xserver. Is it right? > > If it's right, the Xv driver only connected directly with Xserver, and Xserver >communicates with window manager > as s/c. So the same Xv driver should have same effections when we use it at kde or >gnome. But I find that in Xv > driver, some methods of the offscreen video memory allocation is good when we use >gnome but they are very bad > when we use kde. At kde, the window manager may impropriate the video memory you >has allocated in Xv driver > temporarily or maybe they only have been exchanged( I can't make clear what happen, >but the desktop is dirty ). The > situations are very often when I used at virtual screen and only come out when I use >the capture. But they never come out > at gnome. > > I have questioned the driver, but why the driver has different effects at gnome >and kde, maybe the problem is really at > the driver but why there are different effects? Do you meet this situation or give >me some advice? Thank you very much! > I'm not totally following you. Different window managers have different degrees of pixmap usage and XAA will put pixmaps in offscreen memory when they fit. I'm not sure what your question is but I state a few facts about offscreen memory usage. If you allocate offscreen memory with one of the xf86AllocateOffscreen functions and you do not pass a Remove function pointer when you do that, your allocation will be vaild until you free it. You will not lose it. If you do pass a Remove function that allows the offscreen manager to kick you out, and it will call that function when it does. For video, you probably don't want to do that. When you try to allocate, the allocation may fail due to lack of video memory, which can be used by other parts of the server. XAA may be using it for KDE's pixmaps, for example. When this happens you can call xf86PurgeUnlockedOffscreenAreas to kick out many of the expendable allocations that XAA or other parts of the server may have made, and try to allocate again. If you want, you can call one of the xf86QueryLargestOffscreen functions first with PRIORITY_EXTREME for the argument, to see how much room a Purge would give you. It's best if you don't purge if won't give you enough memory. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
> > Jim, if the user is logged in so is the rest of the user interface. Why > not have a monitoring program (like console) that watches the hotplug > events and invokes corresponding configuration program ? This would also > allow for various user environments to customize configuration tools to > match their look. That solution is not in itself sufficient. You might not want everybody to see all hotplug events. Regards Oliver ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Why won't anyone tell me how to get "match edit rgba = rgb" working again ? :-(
On Mon, Feb 04, 2002 at 10:17:49PM +, OS wrote: > Since going up to XFree86 4.2 the line "match edit rgba = rgb" in XftConfig > (the one that gets rid of nasty AA smudges on laptop LCD's) gets dropped > because of a "parsing" error. Can't anyone tell me how to get this working > again. do you have a ; at the end of the line? -pete -- (peter.royal|osi)@pobox.com - http://pobox.com/~osi jabber/ [EMAIL PROTECTED] - icq/ 153025 - aim/ osifx - yahoo/ osi_fx your brain on life - http://fotap.org - incubating msg03967/pgp0.pgp Description: PGP signature
Re: [Xpert]Why won't anyone tell me how to get "match edit rgba = rgb" working again ? :-(
Around 22 o'clock on Feb 4, OS wrote: > match edit rgba = rgb Make that match edit rgba = rgb; Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Why won't anyone tell me how to get "match edit rgba = rgb" working again ? :-(
Hello, Since going up to XFree86 4.2 the line "match edit rgba = rgb" in XftConfig (the one that gets rid of nasty AA smudges on laptop LCD's) gets dropped because of a "parsing" error. Can't anyone tell me how to get this working again. Pretty please, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]OT - How does SGI selling out to M$ affect OpenGL
>Maybe you should take this up on slashdot instead. This isn't > really a good list for conspiracy theories. I did, and it seemed to be confirmed by replies the posting got. In fact some seemed to imply it was worse than I had thought. >Which article was this, and what proof do they have? It was in a British publication called Micro Mart. I haven't contacted them for their proof. > Companies license technology all the time. Not licensed. Bought the patents / IP - I repeat Bought, outright. > And whenever Microsoft is involved alot of people start going into > hysterics, whether it's justified or not. With good reason don't you think. Look what happened to Nokia's micro browser. Look what happened to Sega (I think it was) when they happily agreed to co-develop the X-Box. Look what happened to Kerberos. Need I go on ? >It's silly to talk about what things mean for OpenGL if the premise is false. It not so silly if it's true and if M$ turn round to all OpenGL developers and say "you are now in breach of our patents" !!! Owen On Saturday 02 Feb 2002 10:49 pm, you wrote: > On Sat, 2 Feb 2002, OS wrote: > > Hello, > > > > Appologies if this is too off topic ! > >Maybe you should take this up on slashdot instead. This isn't > really a good list for conspiracy theories. > > > I've just read in a magazine that SGI have sold most, if not all, of > > their patents and IP to M$. The article went on to say that OpenGL is now > > in real trouble and that every one will be forced to move to ActiveX > > whether they like it or not ! Does any one know what this means for Linux > > OpenGL and Linux 3D accellerated graphics stuff. > >Which article was this, and what proof do they have? Companies > license technology all the time. And whenever Microsoft is involved > alot of people start going into hysterics, whether it's justified > or not. It's silly to talk about what things mean for OpenGL if > the premise is false. > > > Mark. > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Sun creator3D DPMS mode, XF86 4.2.0
Attached is a patch to the Sun Creator3D/Elite3D XF86 driver,
sunffb (XF86 4.2.0 release) which works for me on an Ultra 10 with
Creator 3D(Vertical, 2+). I don't know if it works for other
cards supported by this driver.
This patch is the same as the test version for XF86 4.1.99+, except
that
1. It applies to an officially released XF86 version,
2. It does not require that a couple lines be installed into
the header file 'ffb.h' by hand because of some mistake on
my part.
If anyone else uses a creator (or elite) card with XF86 and needs this,
I'd appreciate it if you'ld let me know if this works for you if you
have a chance.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Phone: (703) 392-0303
Fax: (703) 392-0401
--- ffb.h.orig Fri May 4 19:05:46 2001
+++ ffb.h Mon Jan 21 22:26:21 2002
@@ -43,6 +43,14 @@
#include "xf86drm.h"
#include "ffb_drishare.h"
#endif
+/*
+ Bring in the dpms definitions.
+*/
+#ifndef DPMS_SERVER
+#define DPMS_SERVER
+#endif /* DPMS_SERVER */
+#include "extensions/dpms.h"
+
/* Various offsets in virtual (ie. mmap()) spaces Linux and Solaris support. */
/* Note: do not mmap FFB_DFB8R_VOFF and following mappings using one mmap together
@@ -233,6 +241,9 @@
extern void FFBDacFini(FFBPtr);
extern void FFBDacEnterVT(FFBPtr);
extern void FFBDacLeaveVT(FFBPtr);
+extern Bool FFBDacSaveScreen(FFBPtr, int);
+extern void FFBDacDPMSMode(FFBPtr, int, int);
+
/* Exported WID layer routines. */
extern void FFBWidPoolInit(FFBPtr);
--- ffb_dac.c.orig Thu Apr 5 17:42:33 2001
+++ ffb_dac.c Mon Jan 21 22:25:19 2002
@@ -33,6 +33,14 @@
#include "xf86DDC.h"
+/*
+ Used for stabalize time after playing with power management on the display
+*/
+
+#ifndef DPMS_SPIN_COUNT
+#define DPMS_SPIN_COUNT 100
+#endif /* DPMS_SPIN_COUNT */
+
/* Cursor programming */
void
@@ -493,4 +501,119 @@
/* Restore kernel DAC and x-channel state. */
dac_state_restore(pFfb, &p->kern_dac_state);
restore_kernel_xchannel(pFfb);
+}
+
+
+/* DPMS stuff, courtesy of a hint from David S. Miller.
+05.xii.01, FEM
+*/
+
+
+/*
+ I don't know why, if at all, this is needed, but JJ or DSM does it
+ on restore. I observe that when just blanking/unblanking, everything
+ works fine without it, but that sometimes DPMS -> Standby actually
+ results in Off. Maybe related?
+*/
+
+static __inline__ void
+SPIN(ffb_dacPtr d, int count) {
+ while(count-- > 0) {
+(void) DACCFG_READ(d, FFBDAC_CFG_TGVC);
+ }
+ return;
+}
+
+
+/* Screen save (blank) restore */
+
+Bool
+FFBDacSaveScreen(FFBPtr pFfb, int mode) {
+ int tmp;
+ ffb_dacPtr dac;
+ if(!pFfb) return FALSE; /* Is there any way at all this could happen? */
+ else dac = pFfb -> dac;
+
+ tmp = DACCFG_READ(dac, FFBDAC_CFG_TGEN); /* Get the timing information */
+
+ switch(mode) {
+case SCREEN_SAVER_ON:
+case SCREEN_SAVER_CYCLE:
+ tmp &= ~FFBDAC_CFG_TGEN_VIDE; /* Kill the video */
+ break;
+
+case SCREEN_SAVER_OFF:
+case SCREEN_SAVER_FORCER:
+ tmp |= FFBDAC_CFG_TGEN_VIDE; /* Turn the video on */
+ break;
+
+default:
+ return FALSE; /* Don't know what to do; gently fail. */
+ }
+ DACCFG_WRITE(dac, FFBDAC_CFG_TGEN, tmp); /* Restore timing register, video set as
+asked */
+ SPIN(dac, DPMS_SPIN_COUNT/10);
+ return TRUE;
+}
+
+/* DPMS Control, also hinted at by David Miller.
+
+The rule seems to be:
+
+StandBy = -HSYNC +VSYNC -VIDEO
+Suspend = +HSYNC -VSYNC -VIDEO
+Off = -HSYNC -VSYNC -VIDEO
+On = +HSYNC +VSINC +VIDEO
+
+If you don't force video off, someone periodically tries to turn the
+monitor on for some reason. I don't know who or why, so I kill the video
+when trying to go into some sort of energy saving mode. (In real life,
+'xset s blank s xx' could well have taken care of this.)
+
+Also, on MY monitor, StandBy as above defined (-H+V-Vid) in fact
+gives the same as Off, which I don't want. Hence, I just do (-Vid)
+
+05.xii.01, FEM
+08.xii.01, FEM
+*/
+
+void
+FFBDacDPMSMode(FFBPtr pFfb, int DPMSMode, int flags) {
+ int tmp;
+ ffb_dacPtr dac = pFfb -> dac;
+
+ tmp = DACCFG_READ(dac, FFBDAC_CFG_TGEN); /* Get timing control */
+
+ switch(DPMSMode) {
+
+case DPMSModeOn:
+ tmp &= ~(FFBDAC_CFG_TGEN_VSD | FFBDAC_CFG_TGEN_HSD); /* Turn off VSYNC, HSYNC
+ disable bits */
+ tmp |= FFBDAC_CFG_TGEN_VIDE; /* Turn the video on */
+ break;
+
+case DPMSModeStandby:
+#ifdef DPMS_TRUE_STANDBY
+ tmp |= FFBDAC_CFG_TGEN_HSD; /* HSYNC = OFF*/
+#endif /* DPMS_TRUE_STANDBY */
+ tmp &= ~FFBDAC_CFG_TGEN_VSD; /* VSYNC = ON */
+ tmp &= ~FFBDAC_CFG_TGEN_VIDE; /* Kill the video */
+ break;
+
+ca
Re: [Xpert]2 Mice one default - feature request
On Mon, 2002-02-04 at 06:38, jg wrote:
> While your sugestions is a solution it still is really only an
> alternative to what I am calling now ("startx -- -pointer mouse2")
>
> I am very surprised it is not possible to specify a Default
> configuration. Be that a default Mouse (which can be overruled on the
> command line) or as you sugest, a Layout which is Default (thus enabling
> swapping mice on a laptop or other portable computer)
The first ServerLayout section is the default one, isn't it?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon VE <-> ATI Radeon 7500 or Matrox G400?
First of all, see http://gatos.sf.net/ On 4 Feb 2002, Armin Lambacher wrote: > Hello, > > I just switched from a Matrox G400 to an ATI Radeon VE because the > later one has a DVI Connector. System is SuSE Linux 7.3 with the > XFree86 version 4.2.0 from the SuSE update server. After following the > install instructions the card runs. However, there are some issues > comparing it to the former G400 > > - gears seems to be slow. With the matrox card I got frame rates of > about 450 frames per second with the initial Window size. With the > Radeon VE I get about 175 frames per second. > (glxinfo tells me: direct rendering: Yes ) See http://gatos.sf.net/dri-debug.php > > - When I use mplayer to play a video and use -vo xv the video stays > visual if I switch to another desktop. This was not the case with > the matrox card and is very annoying. > This is a known bug, fixed in gatos drivers. > My main concern is the second point. I do not use the 3D acceleration > at the moment, but every now and then want to have a look at a movie > in spare time. I'd like to pause the video, switch to another desktop, > do something there and switch back and continue watching the > video. Would this be possible with the radeon driver? > > And, can I use the TV-out with the Radeon 7500? This code is very experimental.. and was not tested with your card in specifically.. See http://gatos.sf.net/ -> "Watching TV" Vladimir Dergachev > > Thanks a lot > > Armin > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xlib: extension
This indicates you are running an application that depends on the relatively new render extension. The solution is to upgrade you X server (say to 4.1 or 4.2). - Jim Sender: [EMAIL PROTECTED] From: SoloCDM <[EMAIL PROTECTED]> Date: Sun, 3 Feb 2002 22:05:35 -0700 To: Xpert (Request) <[EMAIL PROTECTED]> Subject: [Xpert]Xlib: extension - Recently, I have been receiving the following message when trying to open some programs in X: Xlib: extension "RENDER" missing on display "[IP]:0.0". How can the problem be solved? I changed $DISPLAY from [IP]:0.0 to [IP]:0. -- Note: When you reply to this message, please include the mailing list/newsgroup address and my email address in To:. * Signed, SoloCDM ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ATI Radeon VE <-> ATI Radeon 7500 or Matrox G400?
Hello, I just switched from a Matrox G400 to an ATI Radeon VE because the later one has a DVI Connector. System is SuSE Linux 7.3 with the XFree86 version 4.2.0 from the SuSE update server. After following the install instructions the card runs. However, there are some issues comparing it to the former G400 - gears seems to be slow. With the matrox card I got frame rates of about 450 frames per second with the initial Window size. With the Radeon VE I get about 175 frames per second. (glxinfo tells me: direct rendering: Yes ) - When I use mplayer to play a video and use -vo xv the video stays visual if I switch to another desktop. This was not the case with the matrox card and is very annoying. My main concern is the second point. I do not use the 3D acceleration at the moment, but every now and then want to have a look at a movie in spare time. I'd like to pause the video, switch to another desktop, do something there and switch back and continue watching the video. Would this be possible with the radeon driver? And, can I use the TV-out with the Radeon 7500? Thanks a lot Armin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 CVS-HEAD fixed my monitor?
On Mon, 4 Feb 2002, Shawn Starr wrote: > Ok, Since 4.1.xx.xx i've noticed the monitor unable to resync from console > to 800x600 mode. Something fixed in 4.2.0? :)) > I have an ATI 3D Xpression+ 2MB card (Mach64 GT PCI). > I'm just curious to know what happened. Now I don't have to turn the > monitor off and on waiting for it to finish resyncing the video mode :) Well, you could have also used Option "nocompositesync". Anyway, this showed up after 4.2's release, but is fixed in both the trunk and 4.2 branches. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]2 Mice one default - feature request
Hello,
While your sugestions is a solution it still is really only an
alternative to what I am calling now ("startx -- -pointer mouse2")
I am very surprised it is not possible to specify a Default
configuration. Be that a default Mouse (which can be overruled on the
command line) or as you sugest, a Layout which is Default (thus enabling
swapping mice on a laptop or other portable computer)
What does everyone else think on this issue? I am sure I am not the only
person pining for a simple feature like this to facilitate this.
JG
Galen Brooks wrote:
> If you just want to be able to specify which mouse to use from the command
> line, just use two layouts, and select between them using one of these
> commands:
> "startx -layout layout1"
> "startx -layout layout2"
>
>
>
> Section "ServerLayout"
> Identifier "layout1"
> Screen "screen1"
> InputDevice "mouse1" "CorePointer"
> EndSection
>
> Section "ServerLayout"
> Identifier "layout2"
> Screen "screen1"
> InputDevice "mouse2" "CorePointer"
> EndSection
>
>
> --
> Galen Brooks <[EMAIL PROTECTED]>
> Stop them! They're pirating my vaporware!
>
> On Tue, 29 Jan 2002, J. Grant wrote:
>
>
>>Hello
>>
>>I posted a message last week. I got a reply of a work around from John
>>Tapsell. I had used that work around before.
>>
>>I would like to request that a "default mouse" feature be added. This
>>would be fairly simple to add I think. I am sure that I am not the only
>>one interested in a feature like this.
>>
>>Using the SendCoreEvents means that when i type if I knock the touch pad
>>or buttons on the laptop the cursor jumps to where the mouse is and the
>>text gets typed in the wrong place.
>>
>>The screen section has DefaultColorDepth, this is very useful, I would
>>not want to specify a the color depth each time i use X windows!
>>
>>How about adding a DefaultMouse option?
>>
>>The current situation is this
>>I specify my mouse in the XF86Config-4 file and i get that
>>If i specify another on the command line there is not an error, i just
>>get the XF86Config-4 mouse. (should there be an error?)
>>
>>If there are no mice in the XF86Config-4 and i do not specify one I get
>>an error.
>>
>>What I would be interested in is being able to Override the Mouse in the
>> XF86Config-4 with another one via the command line. That could be by
>>no aditional keywords, just the -pointer option to startx using that
>>one. Or a DefaultMouse = mouse1 option which could be overrident by
>>startx -- -pointer mouse2
>>
>>Has this been considered before? Do you think it is a useful adition?
>>
>>I am subscribed to this list
>>
>>JG
>>
>>-
>>On Monday 21 January 2002 13:58, jg wrote:
>> > Hello
>> > This is my setup
>> >
>> > Section "ServerLayout"
>> > Identifier "layout1"
>> > Screen "screen1"
>> >
>> > # from command line startx -- -pointer
>> > #InputDevice "mouse1" "CorePointer"
>> > #InputDevice "mouse2" "CorePointer"
>>
>>
>>Why not have the second one not CorePointer but SendCoreEvents - that way
>>you can use both mice at the same time :)
>>
>>
>> >
>> > InputDevice "Keyboard1" "CoreKeyboard"
>> > EndSection
>> >
>> > I am using a laptop, I would like my usb mouse2 to be default, but if
>> > the startx -- -pointer mouse1 param is called for that to be used
>> > instead. Is this possible? If i define one in the section above, eg
>> > mouse1 (internal laptop pointer, or PS2 if that is plugged in) then I
>> > can not override it with the startx -- -pointer* mouse2 option.
>> >
>> > 90% of the time I have the USB mouse plugged in, so if i can only change
>> > to the internal/PS2 one by the arguments on the command line that is a
>> > better setup for me.
>> >
>> >
>>
>>
>>
>>___
>>Xpert mailing list
>>[EMAIL PROTECTED]
>>http://XFree86.Org/mailman/listinfo/xpert
>>
>>
>
>
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]2 Mice one default - feature request
Hello,
While your sugestions is a solution it still is really only an
alternative to what I am calling now ("startx -- -pointer mouse2")
I am very surprised it is not possible to specify a Default
configuration. Be that a default Mouse (which can be overruled on the
command line) or as you sugest, a Layout which is Default (thus enabling
swapping mice on a laptop or other portable computer)
What does everyone else think on this issue? I am sure I am not the only
person pining for a simple feature like this to facilitate this.
JG
Galen Brooks wrote:
> If you just want to be able to specify which mouse to use from the command
> line, just use two layouts, and select between them using one of these
> commands:
> "startx -layout layout1"
> "startx -layout layout2"
>
>
>
> Section "ServerLayout"
> Identifier "layout1"
> Screen "screen1"
> InputDevice "mouse1" "CorePointer"
> EndSection
>
> Section "ServerLayout"
> Identifier "layout2"
> Screen "screen1"
> InputDevice "mouse2" "CorePointer"
> EndSection
>
>
>
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Dri-devel] Re: GL testing Re: [Xpert]problem with ati and mandrake 8.1
Daryll Strauss wrote: > > On Sun, Feb 03, 2002 at 08:00:35PM +, Dr Andrew C Aitchison wrote: > > On Sun, 3 Feb 2002, Vladimir Dergachev wrote: > > > > > On Sun, 3 Feb 2002, Dr Andrew C Aitchison wrote: > > > > I'm fairly sure that there is an OpenGL test suite; although I doubt > > > > that it is freely available. Should XFree86 (or another organization) > > > > have a licence that can be used to test DRI ? > > > > > > Well, I tried to search for one and asking on DRI list.. I was not able to > > > compile the GL benchmark (viewperf ?) and there was nothing better, so in > > > the end I settled for testing with Quake, Descent and glxgears. > > > > There is (or used to be) a test suite which an implementation had > > to pass in order to use the OpenGL logo. > > I think that money might have been involved too, although Mesa might > > have been offered an exemption. > > > > Anybody (Brian Paul?) know the details ? > > You're talking about the OpenGL conformance tests. This is a test suite > that tests correctness of some features in OpenGL. You have to sign a > license arrangement with SGI to get access to them as it is part of the > OpenGL branding process. Brian has a copy for his personal use with > Mesa. The tests are not publically available. SGI said at one point that they were going to open-source the tests. I can look into the status of that. > It may be possible for XFree86 to sign an agreement with SGI to get > access to them. VA had worked out a zero cost arrangement with SGI. > > Realize there are some issues with this. If all you want is more tests > to run with OpenGL they would work. You should realize their coverage of > OpenGL is actually quite limited, so passing them doesn't tell you a > lot. No test suite will catch everything but the OpenGL conformance tests really are pretty thorough. Passing them all is in no way trivial. > Also, you can only claim a specific set of binaries pass > conformance. That means XFree could test their releases, but this would > be useless to all the vendors, since they always repackage the release. > > Building a better test suite that is open would be a real > benefit. That's what Glean is all about. I think there'd be more value > in building out Glean than working with the OpenGL brand conformance > tests. Building good tests can be challenging, but it might be a good > project if someone is interested. Yes, it would be great to have more tests contributed to Glean. -Brian ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: User-level Tasks in Hotplug Scripts?
On Sat, 2 Feb 2002 12:55:41 -0800 (PST), Jim Gettys wrote: > OK, folks (both X and wm-spec-list folks, that is, that I've added to > this thread): > > How do we want to solve this problem? > > We need a secure, interoperable way for configuration scripts running > as root to pop up configuration GUI's on user's servers, and we need it soon > (yesterday), as hot-plug is now a reality on Linux systems > > Handling this for the local case is first priority, but we should give some > thought about the possibility that the administrator's display is somewhere > else in the network (e.g. we're configuring a server system's hotplug event, > so the admin is elsewhere). > > Things to keep in the back of our minds is that we already have Kerberos 5 > in the X server and library, so don't dismiss the remote case out of hand. Hi! Maybe the following scheme would suffice: - There's a "hotplug daemon", which gets hotplug events from the kernel. This daemon establishes a listening socket with port<1024. - When an X server is started by a user which wants to deal with hotplug events, the GUI launches a client, let's name it "hotplug commander". The commander connect()s to the daemon and tells him that it wants to receive hotplug events of this, this and this type. - When an actual hotplug occurs, the daemon sends short information packet to all interested commanders. If that action requires some responce from a user, then appropriate password is asked and sent back to the server along with config info (as a variant: the password is asked upon first action, and later that TCP connection is treated by the daemon as "authorized"). So, the pros: - We have an ability to send hotplug events over a network (but by default the socket can be bound to localhost). - The technology of writing secure network daemons is well known (access control, dealing with "bad" clients, secure channels, etc.). - No problem of finding out administrator's display and authenticating to it. - The "hotplug commanders" can be not only GUI apps, but also text-based and even just daemons/robots. BTW, should I cc: to some more addresses? _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Tech Question
I was wondering how X knows when you click on an icon or an application, what was actually clicked, for lack of better words. I am in a Calculs 3 class in college and we are working on Vectors in 2D and 3D. I was wondering how X knows when you click on a certain icon, what application should it run. I was guessing that since X knows the coordinate of the cursor and the coordinate area of the icon, that when you click within that area, it runs the application associated with that area. I was also guessing that X uses the vector to the cursor and that it knows the vectors that correspond to that icon, so therefor knows the application to use. In either case, I was wanting to look at that section of the code and see how it did it. I am a novice programmer with limited programming experiance with C/C++, Perl, and sh. I appreciate any help Thanks Bob - This mail sent through IMP: http://horde.org/imp/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]MGASetupForCPUToScreenTexture() inefficiency
On Don, 2002-01-10 at 04:37, Owen Taylor wrote: > Testing out my rendering code, I noticed that I wasn't getting the > speedups I expected with HW compositing on the MGA. Looking into this, > I discoved that MGASetupForCPUToScreenTexture() copied the entire > source drawable into video memory every time. Since the way that GTK+ > works is to use a different bit of one large source drawable for every > operation, this causing just a bit of a slowdown. > > Here's a patch that fixes this problem by simply allocating the > scratch area in MGASetupForCPUToScreenTexture() and then doing the > copies in MGASubsequentCPUToScreenTexture(). Sounds good, I'll try the same with the r128 and/or radeon drivers once I get RENDER acceleration working there. BTW what are good GTK+ tests for this? > Since this is not an area that I'm very familiar with, I'd appreciate > if someone would look this over - in particular, the way I'm passing > a bunch of parameters from MGASetupForCPUToScreen*Texture() to > MGASubsequentCPUToScreenTexture() using a bunch of static variables > seems ugly, but that was how it was done for tex_padh/padw so I > copied that. I think passing it in the per-screen driver-private data (pMga for the mga driver) would be safer when the driver handles several screens, but maybe that's not an issue. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
On Mon, 4 Feb 2002, Jim Gettys wrote: > Fundamentally, we have no convention right now for any client (root or not) > to connect to an X server except on initiation of the user (unless > the user is silly enough to disable authentication entirely. > > This is an generic X issue (how to delegate authorization to connect). > There is the xauth mechanism, not very secure, but no convention on its > use in these circumstances. There is also support for kerberos, which > is reasonably secure when used properly. And there is SSH, which has > never been integrated into X's world cleanly (and probably should be). > And there is Owen's scheme for > some sort of server process, but this presents much the same fundamental > security/authentication/authorization problem as well. > > I don't have a preconcieved > notion of what the correct solution is; I'm not even very familiar with > the possibilities. > > Certainly, I want no user intervention as much of the time as possible, but > we also need a hotplug design which allows for user intervention at the > time of first use in cases where it may be necessary. The hotplug script > design needs to allow for this, even if it is not the usual case. > And there is need to automatically run GUI based programs, even after > configuration (automatically downloading images off your camera, for > example). > > Personally, I find it very frustrating to have to go looking for a configuration >tool before I can use some hardware: this is not something > a (mere mortal) user knows in advance, and so don't believe the right thing > to do is necessarily nothing (though for much hardware this may be the correct > answer, it isn't for most casually used hardware). > > We can certainly split this discussion to the different communities > if people think that is best, but I wanted to get the problem aired; > there is a problem for each community to mull over at the core of this > problem. > > And someone who sends mail from an address "nogui" certainly has a strong > opinion on the topic, which may not be universal :-;. > - Jim Jim, if the user is logged in so is the rest of the user interface. Why not have a monitoring program (like console) that watches the hotplug events and invokes corresponding configuration program ? This would also allow for various user environments to customize configuration tools to match their look. Vladimir Dergachev > > > -- > Jim Gettys > Cambridge Research Laboratory > Compaq Computer Corporation > [EMAIL PROTECTED] > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tech Question
On Mon, 4 Feb 2002, Bob Bomar wrote: > I was wondering how X knows when you click on an icon or an application, what > was actually clicked, for lack of better words. I am in a Calculs 3 class in > college and we are working on Vectors in 2D and 3D. I was wondering how X > knows when you click on a certain icon, what application should it run. I was > guessing that since X knows the coordinate of the cursor and the coordinate area > of the icon, that when you click within that area, it runs the application > associated with that area. I was also guessing that X uses the vector to the > cursor and that it knows the vectors that correspond to that icon, so therefor > knows the application to use. In either case, I was wanting to look at that > section of the code and see how it did it. I am a novice programmer with > limited programming experiance with C/C++, Perl, and sh. I appreciate any help No, what happens is a little different. Each application, while running, reserves a rectangular part of the screen - a window. Windows can lie in different planes so it is like a pile of paper - all aligned vertically but one can be on top of the other. What X does is intersect them all to find out which regions are visible. And when you click with the mouse it looks up which application owns the area under the mouse and passes the event to it. It is up to the application now to decide what to do with a mouse click. This explanation is somewhat simplistic, since applications can request to monitor all events and can also request to restrict to pass events only to themselves - but read documentation for that :)) If you want to go somewhat deeper in the mathematics of this, take a look at the notion of the "semiring of sets" - the comparison is quite rewarding. Vladimir Dergachev > > > Thanks > > Bob > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: User-level Tasks in Hotplug Scripts?
Fundamentally, we have no convention right now for any client (root or not) to connect to an X server except on initiation of the user (unless the user is silly enough to disable authentication entirely. This is an generic X issue (how to delegate authorization to connect). There is the xauth mechanism, not very secure, but no convention on its use in these circumstances. There is also support for kerberos, which is reasonably secure when used properly. And there is SSH, which has never been integrated into X's world cleanly (and probably should be). And there is Owen's scheme for some sort of server process, but this presents much the same fundamental security/authentication/authorization problem as well. I don't have a preconcieved notion of what the correct solution is; I'm not even very familiar with the possibilities. Certainly, I want no user intervention as much of the time as possible, but we also need a hotplug design which allows for user intervention at the time of first use in cases where it may be necessary. The hotplug script design needs to allow for this, even if it is not the usual case. And there is need to automatically run GUI based programs, even after configuration (automatically downloading images off your camera, for example). Personally, I find it very frustrating to have to go looking for a configuration tool before I can use some hardware: this is not something a (mere mortal) user knows in advance, and so don't believe the right thing to do is necessarily nothing (though for much hardware this may be the correct answer, it isn't for most casually used hardware). We can certainly split this discussion to the different communities if people think that is best, but I wanted to get the problem aired; there is a problem for each community to mull over at the core of this problem. And someone who sends mail from an address "nogui" certainly has a strong opinion on the topic, which may not be universal :-;. - Jim -- Jim Gettys Cambridge Research Laboratory Compaq Computer Corporation [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Tech Question
I was wondering how X knows when you click on an icon or an application, what was actually clicked, for lack of better words. I am in a Calculs 3 class in college and we are working on Vectors in 2D and 3D. I was wondering how X knows when you click on a certain icon, what application should it run. I was guessing that since X knows the coordinate of the cursor and the coordinate area of the icon, that when you click within that area, it runs the application associated with that area. I was also guessing that X uses the vector to the cursor and that it knows the vectors that correspond to that icon, so therefor knows the application to use. In either case, I was wanting to look at that section of the code and see how it did it. I am a novice programmer with limited programming experiance with C/C++, Perl, and sh. I appreciate any help Thanks Bob ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]2 Mice one default - feature request
On Mon, 4 Feb 2002, openssh wrote: > I am very surprised it is not possible to specify a Default > configuration. Be that a default Mouse (which can be overruled on the > command line) or as you sugest, a Layout which is Default (thus enabling > swapping mice on a laptop or other portable computer) A default mouse is a reasonable idea. You are the one who wants it most, so why don't you write a patch and submit it to [EMAIL PROTECTED] ? > What does everyone else think on this issue? I am sure I am not the only > person pining for a simple feature like this to facilitate this. > DefaultDepth for the resolution exists as I pointed out before. I can use the same config and layout with my laptop's built in touch pad or with both that and and a USB mouse, using the config in: http://www.xfree86.org/pipermail/xpert/2001-June/008690.html plugging the external mouse in and out is fine, although the external mouse may not be available if the usb kernel modules are not loaded when the X server starts. I think that your problems are unusual, since most laptops don't have touch pads which get in the way when typing. Although I hate it, I suppose that the window managers which use "click to change focus" will help to hide this problem too. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]horizontal "rain"
hi
i got debian installed now and all is ok
two video cards two monitors ...
on the ATI card the blinking is gone with the nosync option
but the SiS card when i move a window or the cursor, it show some kinda
of horizontal "rain" i cant explain it better this !
any idea would help !!
thanks again
333
xdpyinfo:
jul:~# xdpyinfo
name of display::0.0
version number:11.0
vendor string:The XFree86 Project, Inc
vendor release number:4011
XFree86 version: 4.1.0.1
maximum request size: 4194300 bytes
motion buffer size: 256
bitmap unit, bit order, padding:32, LSBFirst, 32
image byte order:LSBFirst
number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
focus: window 0x3800013, revert to Parent
number of extensions:30
BIG-REQUESTS
DPMS
Extended-Visual-Information
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X3D-PEX
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-DRI
XFree86-Misc
XFree86-VidModeExtension
XIE
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number:0
number of screens:1
screen #0:
dimensions:2800x1050 pixels (712x267 millimeters)
resolution:100x100 dots per inch
depths (1):16
root window id:0x3c
depth of root window:16 planes
number of colormaps:minimum 1, maximum 1
default colormap:0x20
default number of colormap cells:64
preallocated pixels:black 0, white 65535
options:backing-store NO, save-unders NO
largest cursor:64x64
current input event mask:0x5a20bd
KeyPressMask ButtonPressMask
ButtonReleaseMask
EnterWindowMask LeaveWindowMask
PointerMotionHintMask
ButtonMotionMask StructureNotifyMask
SubstructureNotifyMask
SubstructureRedirectMask PropertyChangeMask
number of visuals:2
default visual id: 0x23
visual:
visual id:0x23
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
visual:
visual id:0x24
class:TrueColor
depth:16 planes
available colormap entries:64 per subfield
red, green, blue masks:0xf800, 0x7e0, 0x1f
significant bits in color specification:6 bits
jul:~#
333
lspci
##3
jul:~# lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev
03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:03.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev
05)
00:04.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
00:09.0 Multimedia audio controller: ESS Technology ES1969 Solo-1
Audiodrive (rev 01)
00:12.0 VGA compatible controller: Silicon Integrated Systems [SiS]
86C326 (rev 0b)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP
(rev 7a)
jul:~#
###333
thank you!
On Mon, 2002-02-04 at 10:36, openssh wrote:
> Hello,
>
> While your sugestions is a solution it still is really only an
> alternative to what I am calling now ("startx -- -pointer mouse2")
>
> I am very surprised it is not possible to specify a Default
> configuration. Be that a default Mouse (which can be overruled on the
> command line) or as you sugest, a Layout which is Default (thus enabling
> swapping mice on a laptop or other portable computer)
>
> What does everyone else think on this issue? I am sure I am not the only
> person pining for a simple feature like this to facilitate this.
> DefaultDepth for the resolution exists as I pointed out before.
>
> JG
>
>
> Galen Brooks wrote:
>
> > If you just want to be able to specify which mouse to use from the command
> > line, just use two layouts, and select between them using one of these
> > commands:
> > "startx -layout layout1"
> > "startx -layout layout2"
> >
> >
> >
> > Section "ServerLayout"
> > Identifier "layout1"
> > Screen "screen1"
> > InputDevice "mouse1" "CorePointer"
> > EndSection
> >
> > Section "ServerLayout"
> > Identifier "layout2"
> > Screen "screen1"
> > Inpu
Re: [Xpert]2 Mice one default - feature request
Hello,
While your sugestions is a solution it still is really only an
alternative to what I am calling now ("startx -- -pointer mouse2")
I am very surprised it is not possible to specify a Default
configuration. Be that a default Mouse (which can be overruled on the
command line) or as you sugest, a Layout which is Default (thus enabling
swapping mice on a laptop or other portable computer)
What does everyone else think on this issue? I am sure I am not the only
person pining for a simple feature like this to facilitate this.
DefaultDepth for the resolution exists as I pointed out before.
JG
Galen Brooks wrote:
> If you just want to be able to specify which mouse to use from the command
> line, just use two layouts, and select between them using one of these
> commands:
> "startx -layout layout1"
> "startx -layout layout2"
>
>
>
> Section "ServerLayout"
> Identifier "layout1"
> Screen "screen1"
> InputDevice "mouse1" "CorePointer"
> EndSection
>
> Section "ServerLayout"
> Identifier "layout2"
> Screen "screen1"
> InputDevice "mouse2" "CorePointer"
> EndSection
>
>
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]A question about: Xv driver, xserver and kde or gnome
Hi, The question has troubled me very long. I don't know the where is the trouble. In my thought,Xv driver belong to the DDX layer of Xserver, and kde or gnome are the app(window manager) build upon Xserver. Is it right? If it's right, the Xv driver only connected directly with Xserver, and Xserver communicates with window manager as s/c. So the same Xv driver should have same effections when we use it at kde or gnome. But I find that in Xv driver, some methods of the offscreen video memory allocation is good when we use gnome but they are very bad when we use kde. At kde, the window manager may impropriate the video memory you has allocated in Xv driver temporarily or maybe they only have been exchanged( I can't make clear what happen, but the desktop is dirty ). The situations are very often when I used at virtual screen and only come out when I use the capture. But they never come out at gnome. I have questioned the driver, but why the driver has different effects at gnome and kde, maybe the problem is really at the driver but why there are different effects? Do you meet this situation or give me some advice? Thank you very much! Regards, Hzeng ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
