Re: [Xpert]void driver?
On July 25, 2002 01:08 am, [EMAIL PROTECTED] wrote about [Xpert]void driver?: Section InputDevice Identifier DummyKeyboard Driver void EndSection Does the void driver still try to allocate a VT? Can it be used on the XServer where the second XServer is configured for a secondary video card, without messing with the first video card/console? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]USB Keypad
On July 18, 2002 08:09 pm, Josh Litherland wrote about [Xpert]USB Keypad: I want to simultaneously use a PS/2 keyboard (This is a laptop, so switching that out is not an option) and a USB numeric keypad, which works perfectly as a usb HID keyboard. Is there any way to do this with the current keyboard driver ? (I'm assuming your using some flavour of Linux 2.4.x such as RedHat 7.x, Mandrake 8.x etc) Just plug it in and it should work. I have a PS/2 keyboard and a USB Keyboard plugged in at the same time right now and they both work fine. Most recent distros it should be as simple as that. If that doesn't work, make sure these kernel modules are loaded: keybdev hid input usb-ohci or usb-uhci, depending on your usb controller usbcore ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]2 mice with 2 mouse pointer
On July 10, 2002 12:32 am, Nick Name wrote about Re: [Xpert]2 mice with 2 mouse pointer: Still I can't see the point-er :) What use could a second pointer be of? If you're doing CAD or GIS work, the second pointer could be a digitizer. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]linux font path error
On June 24, 2002 03:31 pm, John Herrington wrote about [Xpert]linux font path error: I'm having a problem with my Xserver that I have never seen before. I have been running Xfree86 happily on my X86 Linux box (Red Hat 7.2/KDE) for about a year now, with no problems, and the other day I suddenly started getting the following error message when booting up: - (II) XINPUT: Adding extended input device Mouse0 (type: MOUSE) Could not init font path element unix/:7100, removing from list! Fatal server error: could not open default font 'fixed' sounds like xfs isn't running. if test ! -f /etc/rc.d/rc5.d/S90xfs; then ln -s /etc/rc.d/init.d/xfs /etc/rc.d/rc5.d/S90xfs; fi /etc/rc.d/init.d/xfs start startx If you can then run X, all is good. telinit 5 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X Port numbers not be reused
On May 24, 2002 07:53 am, Mark Cuss wrote: We run a RedHat 7.2 server in our office (been up for 180 days). We run X on the server, and clients connect to the server with their Windows boxes using Exceed. This had always worked very well untilyesterday ... the port numbers have slowly crawled up to the 50,000 range. In this case, Exceed on your desktops are the servers, the applications on your Linux Box are the clients. Applications on the Linux Box connect to the Server on a user's desktop on port 6000. If there are high numbered ports being used on the Linux box, it is very likely something else that is useing the ports. type: netstat --ip -l -p -e as root on the Linux Box to see who is running what program listening on what port. There may be steadily increasing-source-ported out-going connections if your users use webbrowsers on the Linux Box and do not log out each night. This shouldn't interfere with your system anyways. I tried killing the X server (CTRL-ALT-BACKSPACE). I also tried restarting the xfs service as well as the network service but with no luck - X continues to use ports in the 50,000 range instead of starting again at the first free port after 6000. It's Probably not X useing these ports. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding more keyboards and mice
Hmmm... OK, but this gives us only the VT's, keyboards and mice - the video problem is the same, isn't it? That is, unless we want to use the fbdev, losing all acceleration and support for many cards. Or am I wrong - is there some acceleration in the framebuffer and its X driver? You are wrong. There is no accelleration in fbdev. I did not just contradict myself. it will become clear further down this message. XFree currently expects that it is the only program accessing any video hardware, XFree assumes it is the only program accessing that particular card. If I remember correctly, the original VGA has I/O ports at somewhere around 0x3C0, and memory at ... Again, if I understand correctly, for multiple X servers we would have to isolate all shared I/O port accesses and enclose them in lock acquire/lock release. For the rest of the servers' lifetime (when no mode change is occuring), the cards' I/O access should stay disabled. Right? Wrong. Now, please tell me, someone knowledgeable, if my above written guesses and conclusions are anywhere near the truth. :-) Thanks. Nope. In the positive case, is it even possible to isolate I/O accesses in a driver-independent way? Where would I start? I'm willing to try to do the hard work, but I need guidance from someone who understands XFree internals. (Even then, it may prove to be too much for me...) From `man 5 XF86Config`: DEVICE SECTION ... BusID bus-id This specifies the bus location of the graphics card. For PCI/AGP cards, the bus-id string has the form PCI:bus:device:func tion (e.g., PCI:1:0:0 might be appropriate for an AGP card). This field is usually optional in single-head configurations when using the primary graphics card. In multi-head configurations, or when using a secondary graphics card in a single-head configuration, this entry is mandatory. Its main purpose is to make an unambiguous connection between the device section and the hardware it is representing. This information can usually be found by running the X server with the -scanpci command line option. In other words, all the work involving the Video card is already done. It might even work with cards that do multiple heads on the same card (the function parameter). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding more keyboards and mice
On May 24, 2002 10:12 am, Michel Dänzer wrote: On Fri, 2002-05-24 at 19:08, Trent Whaley wrote: From `man 5 XF86Config`: DEVICE SECTION ... BusID bus-id ... In other words, all the work involving the Video card is already done. Now you are wrong. :) The X server disables video devices it doesn't use. DOH! That seems like a really dumb Idea. Is it easy to make it not disable the other cards? Would that gum up other stuff? It might even work with cards that do multiple heads on the same card (the function parameter). Might work if the chips offered several functions, but they don't AFAICS. Bummer. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding more keyboards and mice
Quotes come from several messages on this thread. The way I see is providing multiple event queues, one for each user (=screen, or even set of screens), and attach one keyboard and one mouse to each queue. And make one mouse cursor for each queue. I'm probably missing something important, but on first view, that seems to be it. Any insight? This is very bad. Each user should have their own server. It's just easier, more elegant, more secure, and more stable that way. What if one user logs out? this kills the X-Server. Or were you planning on re-writing the XDM protocol too? What if one user's app listens to events for the other's screen while the other user is typing in a passphrase? What if one user starts running a GL-intensive app? I think the way to go is to modify the X-Server so that grabbing a VT is optional, and the default keyboard device is configureable and modular (thus allowing many types of device). This solves all your problems. Then all you have to do is set up several configurations and tell it which to run on the command line (or XDM config file). Everything but setting the VT grabbing optional and modularizing the keyboard input is already done. I think a better way would be to use only one instance of XFree, have it handle multiple monitors (that already works just fine!) WITHOUT Xinerama, and add more event queues, each for one screen/user. And of course, add support for multiple (USB) keyboards (at least two solutions exist) and multiple mice with one cursor each. There is a one to one relationship between users and XServers for good reason. Without seperation of servers, events of one user could affect the other. How does a program know that :0.0 is it's user's and :0.1 is not? With seperate Servers, either with no VT code or with the new linuxconsole kernel patches, the two servers are completely seperate, thus greatly reducing the changes to X that are nescesary and eliminated the need for changes to the X protocol and client applications. 2) You could not go through the kernel and instead attempt to access the video card manually or through the frame buffer or something smart - and some has done this, and posted various patches.. although that still only allows a max of two heads. Or you could use the LinuxConsole kernel patches (linuxconsole.sourceforge.net) to set up multiple consoles. You may need to modify X to do it this way, I've only read the linuxconsole web pages; I haven't tried it. I don't quite understand what you mean by this, but again - I don't think this is the problem, multi-head support is already working. (Maybe not for all cards, though.) Multi-head on one server is a completely different thing from having multiple users. I don't think the X protocol has anything to do with it. Isn't the multi-screen support much like two independent X servers already? How closely coupled are screens :0.0 and :0.1? They run on the same server, and are therefore are owned by the same user, and are associated with the same socket (usu. 6000). It would Be WAY more work to get one server to support two sessions at the same time than to just run two seperate servers, decoupled from the VT system. 5) It is hard getting many monitors on a machine simply because the cables aren't that long! The longer you make the cable, the worse the image gets on the monitor. I think you can get round this by using LCD screens - but can't remember for sure. This may be a practical problem in some cases, and no problem at all in other. Think classrooms, internet cafe's... Many monitors (and computers, needlessly) stacked one right by the other, very close. Monitor cables are often four feet long. If you put the computer at desktop height instead of on the floor, Two users could be up to 8 feet apart. 6) A nicer way of doing all of this is simply to have lots of very cheap nasty machines with nothing but a mobo, CPU, ethernet card and monitor - then get one big server to control them all. See the linux terminal server project. One cheap nasty machine with nothing but a mobo, CPU, ethernet card and monitor, plus 3 video cards (plus one onboard) and monitors is bound to be cheaper. Plus imagine how much easier it would be for a VAR to sell Linux (or other free *NIX) if someone could come into their shop expecting to buy a new computer and walk out with a video card, monitor, keyboard, and mouse. There's more to it than that, albiet in little ways. Who gets sound? Who Gets floppy/cdrom? I'll admit that I don't hang out in internet cafes, so those may not be available anyways normally. Plus, you mention VGA and monitor which you'll need anyways. Sound? For office settings, sound cards are often disabled, removed, or declared off limits anyways, to avoid annoying co-workers. In an internet cafe you could install multiple sound cards just like the video cards. floppy/cdrom? With central backups and
