Re: XI2 pull warning
you're certainly keeping me busy :) thanks for all those reports On Sat, May 30, 2009 at 10:59:28AM -0400, Thomas Jaeger wrote: Peter Hutterer wrote: On Thu, May 28, 2009 at 02:54:22PM -0400, Thomas Jaeger wrote: Thanks for the work you've put into this. I haven't spent a lot of time testing the new code, but here are my first impressions. You're probably aware of most of the issues below already, but I'll mention them just in case. * The biggest issue for me right now is reporting of XI1 (see the attached test program). XSelectExtensionEvents and XGrabDevice/XGrabDeviceButton will only report press events; motion and release events are lost. Fixed. missing mask assignment in the case of an explicit passive grab. Thanks, this is working now. However, xournal is still won't accept any input (unless patched) because it discards events due to device_state not being set correctly. confirmed. I need to write a simple test program to check what exactly is going on there, I haven't found the exact source for the bug yet. * A driver sending a proximity event crashes the server. Fixed, thanks. GetProximityEvents still had the valuator event calculation in there and returned a wrong number of events. That, an an uninitialized pointer that was only triggerd for proximity events. Both fixes pushed. Thanks, this is mostly working now. There are still instances where proximity events lead to a crash, see the attached gdb session. I can't reproduce this after the load of patches I just pushed, so I'm assuming one of them fixed it :) * XIGrabButton always fails with a BadDevice error. Fixed, thanks. The check was in there to prevent passive grabbing of attaches slave devices, which in hindsight might have its use-cases though dealing with the modifiers can be trick. Documented in inputproto. It seems like XIGrabButton doesn't accept XIAnyModifier. this part was simply missing. It's implemented now and works. Also, a passive grab on XIAllDevices and XIAllMasterDevices works now. Also, the example code in xinput uses an older incompatible interface (patch attached). oops. I fixed this at least three times but each time forgot to push. sorry. pushed now. If XIGrabButton is called on a SD, the SD is not detached when the grab is activated. fixed. SDs are now detached for passive grabs, except if an implicit passive grab is activated. * libXi doens't support parallel builds (make -j2) anymore. works fine for me, not sure what's going on there. Okay, fair enough, this is not really important anyway. actually, the reason for this could be a missing dependency in the man pages. If you can reproduce this error, just check the Makefile.am for the dependency setup for the file it fails on. I've tried triggering it but without success. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
Well, Im supposing I'll be able to switch between desktops so fast that I'll be able to keep up with the refresh rate and with human eye's perception of image change, so that the screen doesnt go black and the user doesnt notice his screen is acting like a super fast slideshow (switching frames all the time). I'm a complete newbie to X, so take everything I say with a grain of salt, but I doubt that you'll be able to do this without purchasing some good (read: expensive) hardware and doing some _heavy_ hacking on X and some heavy hard hacking. My understanding of video signals tells me that this probably won't work. I would hazard a guess and simply say that your usage case is at least close to impossible, if not completely impossible. I've implemented a pong-like animation using just hardware on a Xilinx FPGA over the VGA port, but I don't think you'll be able to find an FPGA with 2 VGA outputs. This means that you may be forced to design and implement your own circuit from scratch, which is not a trivial task. Heck, best of luck to you if you decide to try to implement it anyway, though. Be sure to post pics and a rough guide of what you did and how to do it if the project becomes unique enough to warrant it. -- andruk Luca Bezerra wrote: Well, I have no experience on any of the areas of the questions above, so my answers will be based solely on my guessings and on what I've learned from researching on the internet. - You are potentially flooding applications with map/unmap requests (due to the virtual desktop switching), but let's assume you have a custom window manager which doesn't do that. A: Ok, moving on... - How will you ever get something async like the X protocol to synchronize with this external hardware? A: I had no clue about X being asyncronous, or about what that means on this subject.. I'd really appreciate if you could give me more info about that :) - Virtual desktops belong to a single user, how do you expect them to behave nicely for multiple users? A: I dont know if I didnt get what you meant, but here's the answer to what I think you meant. The idea isnt of multiple logins sharing the same X session (and their virtual desktops). What Im trying to do is to have a unique user (lets say John) logged in. After I log in as John, its like I have simply 4 regular virtual desktops, each one with a browser open. The system will work as if I were constantly switching the desktops. Let's say I go to D1 and move my cursor 1/2, go to D2 and type letter 'a', go to D3 and do alt+tab and then go back to D1 and move another 1/2, and so on. The way I see, it'd be like a single person using multiple desktops really fast, not really multiple users (at least the operating system wouldnt see it that way, would it?). - What about the mouse pointer, isn't it kind of expensive/slow to render many software cursors on an old system? A: As I said, based solely on my researches, I dont really think that would be a problem. Existing (and functional) multiseat systems do use multiple mice and keyboard and they get along pretty well... - What happens to refresh rate? A: Assuming you're talking about when I cut the image flow to one monitor and switch it to another, how is that first monitor going to keep the image in there while no image is really being sent to it, the answer is.. Well, Im supposing I'll be able to switch between desktops so fast that I'll be able to keep up with the refresh rate and with human eye's perception of image change, so that the screen doesnt go black and the user doesnt notice his screen is acting like a super fast slideshow (switching frames all the time). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
This may not be helpful at the moment, but should you decide that you need to go down the multiple displays route eventually, there exist screen cards that do 4 VGA ports on the one card. Unfortunately the only one I know of requires PCI Express, but I'm fairly sure there are others. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: (Intel 965) Upgrade to xorg-server 1.6.1, Linux 2.6.30, KMS - Problems with Xv, GL
Johannes Truschnigg wrote: x) Logging out of KDE (using KDM, KDE 3.5.10) crashes the X server, and the screen stays blank/black True even without drm. I filed a bugreport regarding this, but mine is probably just ignored because I don't use Linux. https://bugs.freedesktop.org/show_bug.cgi?id=21831 x) Playing back video with mplayer (1.0rc2) using Xv crashes the system hard x) Playing back video with mplayer using -vo gl or -vo gl2 woks, but when mplayer exits (due to the end of the video stream being reached, or closing its window) results in a backtrace like the following: http://pasted.at/99f86c09fd.html - I have to kill -9 mplayer afterwards to destroy the video window. That's particulary annoying when playing back videos full screen. Switching to a VT does work here though, even after mplayer crashed in fullscreen mode. x) if KMS is NOT enabled, the error I described above proves fatal to the system, and I have to reset my machine as a whole. That what happens to me because the OS I happen to use (DragonFly BSD) doesn't have KMS support. Also happens with tuxracer for example here. Anyway, I'm rather sad to see the intel driver in the state in which it is at the moment. Every release since 2.4 series has been only regression for me. So far there has been workaround for me to get at least 2d working without crashes (without drm) and with acceptable performance - XAA. But with 2.7.x it doesn't work either any more: https://bugs.launchpad.net/bugs/360921 Sorry to say that, but even the Nvidia binary driver (I can use the one for FreeBSD on DragonFly with quite ugly hacks) has been better choice. -- Hasso Tepper ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
@Andruk: I'm a complete newbie to X, so take everything I say with a grain of salt, but I doubt that you'll be able to do this without purchasing some good (read: expensive) hardware and doing some _heavy_ hacking on X and some heavy hard hacking. My understanding of video signals tells me that this probably won't work. I would hazard a guess and simply say that your usage case is at least close to impossible, if not completely impossible. A: Im no expert either (far from that, actually), but I think the good/expensive hardware wont be necessary.. I mean, if I choose to have like 10 virtual desktops and hold down Ctrl+Alt+Right Arrow Key, the VD's change so fast until the last one that I can barely notice anything... And thats on a low configuration machine. About the heavy hacking on X, yes, thats more likely.. I have no clue if I'll be able to do it, since, as Ive said, Im no expert on this, but.. Lets see how far can I go :P I've implemented a pong-like animation using just hardware on a Xilinx FPGA over the VGA port, but I don't think you'll be able to find an FPGA with 2 VGA outputs. This means that you may be forced to design and implement your own circuit from scratch, which is not a trivial task. A: Forgot to mention on my huge explanation.. The external circuit won't be build by me, but by my boss, who's graduated (PhD maybe, not sure) in electronics (or something like that). He wants me to be able to switch desktops and send the synchronized signals through the parallel port (which is no easy task anyway ._.). Heck, best of luck to you if you decide to try to implement it anyway, though. Be sure to post pics and a rough guide of what you did and how to do it if the project becomes unique enough to warrant it. A: Thanks, be sure I'll post all about it if I manage to do such thing :P -- @Tim Nelson: This may not be helpful at the moment, but should you decide that you need to go down the multiple displays route eventually, there exist screen cards that do 4 VGA ports on the one card. Unfortunately the only one I know of requires PCI Express, but I'm fairly sure there are others. A: Yeah, I hadnt heard of the existance of 4 headed graphic boards, until like half an hour ago, when someone mentioned you could find 4 headed PCI graphic boards easily on eBay (cant really remember who it was, sorry :S so many messages coming at once...). Ive already wrote down this 4 headed graphic cards alternative as my last try, when there are no more options available, thanks for the tip! :D ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
Hi Luca, A: Im no expert either (far from that, actually), but I think the good/expensive hardware wont be necessary.. I mean, if I choose to have like 10 virtual desktops and hold down Ctrl+Alt+Right Arrow Key, the VD's change so fast until the last one that I can barely notice anything... And thats on a low configuration machine. But that is on a single monitor. If I understand your intent correctly, you want to multiplex the signal over 10 different monitors, which is the real challenge here. I'm not so sure what a monitor does when you suddenly disconnect it for a (short) while, since it will probably lose the syncing signals. If you build your hardware clever enough so it will always connect the syncing signals to all monitors, and connect the signal pins to ground (or something) when the monitor is not selected, this might work, provided that your monitor is slow enough (if it switches to black fast enough, you'll be looking at a monitor that is black 9/10th of the time). Apart from that problem, I think timing will be critical here. Even if you can switch fast enough, you should make sure that you're switching the virtual desktop (ie, the image on the VGA output) at exactly the same moment as you're switching the output in your switchbox. Any offset here means that the image of one screen is visible on another screen, which might not bee all too noticable, but will probably lead to a lot of people with a headache in the long run. Not trying to demotivate you, but I have serious doubts about the feasibility of your approach (that, or I'm completely misunderstanding what you're trying to do...). Going down the typical multihead road with at least one VGA output per display is probably going to be a lot easier (but still challenging to get working properly probably, if you're going to share an X server between multiple users). I'd expect that PCI videocards should be available in plenty in the second hand market, lots of people still have them piling up at home I think. Gr. Matthijs signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XI2 pull warning
Peter Hutterer wrote: * A driver sending a proximity event crashes the server. Fixed, thanks. GetProximityEvents still had the valuator event calculation in there and returned a wrong number of events. That, an an uninitialized pointer that was only triggerd for proximity events. Both fixes pushed. Thanks, this is mostly working now. There are still instances where proximity events lead to a crash, see the attached gdb session. I can't reproduce this after the load of patches I just pushed, so I'm assuming one of them fixed it :) I can still reproduce it. It happens when a proximity event comes in when the SD is grabbed. If XIGrabButton is called on a SD, the SD is not detached when the grab is activated. fixed. SDs are now detached for passive grabs, except if an implicit passive grab is activated. Thanks, XIGrabButton on SDs is mostly working now. The only problem is that the original Press event is still delivered, which leads to inconsistent state on the MD until the button is pressed on another SD. * libXi doens't support parallel builds (make -j2) anymore. works fine for me, not sure what's going on there. Okay, fair enough, this is not really important anyway. actually, the reason for this could be a missing dependency in the man pages. If you can reproduce this error, just check the Makefile.am for the dependency setup for the file it fails on. I've tried triggering it but without success. My theory is that it's a race condition, where due to the recursive call of make the same man page is built at the same time by both processes and then the second mv fails. Thanks, Tom ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ./install-sh: no input file specified.
Dan Nicholson wrote: On Mon, Jun 1, 2009 at 9:25 PM, jspran...@awlship.com wrote: I have finally gotten autogen.sh to complete without failing. I really just want to build kdrive, not the whole xserver. I have seen threads stating a --enable-kdrive option but I still don't exactly know where that option is put. Is it when I run autogen.sh? I tried to run install.sh and I got the following error: ./install-sh: no input file specified. Can someone please help me through this. You're missing some of the basics of building software and this isn't really the place to learn them. Follow the instructions from the wiki (in particular, the part titled Building the X Server). http://xorg.freedesktop.org/wiki/Development/git -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I realize I am a bit off on this, thanks for the link. I apologize for posting to the wrong list. -- Joe Sprankle AGAPE WORLDWIDE LOGISTICS P (714)952-0360 F(714)952-0361 C(714)454-7189 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] libICE: Don't use _IceTransIsLocal in IceComposeNetworkList
This saves an extra loop from firing off when there's a non-local socket among
the connections. (Since all _IceTransLocal does is check if the socket is a
UNIX type.)
diff --git a/src/listen.c b/src/listen.c
index eb46f87..efd85bd 100644
--- a/src/listen.c
+++ b/src/listen.c
@@ -207,27 +207,10 @@ IceComposeNetworkIdList (
for (i = 0; i count; i++)
{
-if (_IceTransIsLocal (listenObjs[i]-trans_conn))
-{
-strcat (list, listenObjs[i]-network_id);
-doneCount++;
-if (doneCount count)
-strcat (list, ,);
-}
-}
-
-if (doneCount count)
-{
-for (i = 0; i count; i++)
-{
-if (!_IceTransIsLocal (listenObjs[i]-trans_conn))
-{
-strcat (list, listenObjs[i]-network_id);
-doneCount++;
-if (doneCount count)
-strcat (list, ,);
-}
-}
+strcat (list, listenObjs[i]-network_id);
+doneCount++;
+if (doneCount count)
+strcat (list, ,);
}
return (list);
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XI2 pull warning
On Tue, Jun 2, 2009 at 8:24 AM, Thomas Jaeger thjae...@gmail.com wrote: Peter Hutterer wrote: actually, the reason for this could be a missing dependency in the man pages. If you can reproduce this error, just check the Makefile.am for the dependency setup for the file it fails on. I've tried triggering it but without success. My theory is that it's a race condition, where due to the recursive call of make the same man page is built at the same time by both processes and then the second mv fails. Can you show the error? -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
help configuring a 30 apple cinema display
Hi all: I'm having some trouble getting my apple cinema displays to run properly. I have two of them, a 23 one (DVI0) and a 30 one (DVI1). here's the output from xrandr: Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 4480 x 1600 VGA1 disconnected DVI0 connected 1920x1200+0+0 495mm x 310mm 1920x1200 59.9*+ 60.0 VGA2 disconnected DVI1 connected 1280x800+1920+400 641mm x 401mm 1280x800 59.9* which I think means I need to add a mode to get the DVI1 one to 2560x1600. So I did this: xrandr --output DVI1 --newmode 2560x1600 348.50 2560 2760 3032 3504 1600 1603 1609 1658 -hsync +vsync which seemed to succed, but then I get this: xrandr --output DVI1 --mode 2560x1600 xrandr: cannot find mode 2560x1600 Any ideas what I'm doing wrong? Thanks, Robby ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
It's not possible without some fancy hardware in the switch box: if you're going with your six-monitor setup and a simple A-B-C switch, each monitor needs to be able to handle a refresh rate of at least 360Hz to avoid flicker (I don't know of any CRT that can do more than 160Hz; it's rare for LCDs to handle more than 75Hz), and will be seeing no signal for five out of every six frames (any modern monitor will realize it's lost sync and will go into standby). In order to get this to work, the switch box needs to capture the video signal for a frame, store it, and repeat it on a given monitor's output until a new frame for that monitor comes along. Once that's done, the rest of the problem becomes trivial. It would be easier (and probably faster and cheaper) to lurk on Ebay until you can find a four-port PCI video card. -- Mark A: This framebuffer idea seems to be the closer one from the ideal solution for this problem, given the circumstancies. A couple of people mentioned it to me today (some from here, some from my college), but I appreciate your data about the monitor's frequencies, it'll be very useful once Im reporting my progress and obstacles to my boss ;) The thing about buying on eBay, as I said before, is that its not easy to get money released from the government to buy stuff for such an unusual project, let alone tell them we're not buying from a store or a company, but from a online commerce website... It'd never be approved; The contract would have to be made with some company, in order to be supplied with x LCD monitors (at a lower cost, obviously, due to the ammount required). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
Don't forget also: if you pay for your own electricity, then buying a cheap LCD is cheaper than using a free CRT for three to six months. - d. A: True. Not only the electricity economy, but also because CRT monitors are really big (students knees would be constantly hitting the bottom of it, and they wouldnt be able to sit correctly at the table) and heavy (attaching 6 CRT monitors screen-up position to a simple wooden table would be both hard and unsafe, since their weight plus some eventual student supporting himself on the table could make it crash or something). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
2009/6/2 Luca Bezerra lucabeze...@gmail.com: Don't forget also: if you pay for your own electricity, then buying a cheap LCD is cheaper than using a free CRT for three to six months. A: True. Not only the electricity economy, but also because CRT monitors are really big (students knees would be constantly hitting the bottom of it, and they wouldnt be able to sit correctly at the table) and heavy (attaching 6 CRT monitors screen-up position to a simple wooden table would be both hard and unsafe, since their weight plus some eventual student supporting himself on the table could make it crash or something). I gave away a 21 Sun CRT a few years ago. On Freecycle, none of my friends wanted it. I tried giving another one away a few months ago and couldn't even Freecycle it. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
Luca, The project you describe is much harder than is reasonable for a single person on a tight budget and has some problems you might not recognize. Driving multiple monitors off of one video in a way that is usable isn't as simple as rapidly switching the signal lines. I believe it takes at least one full video frame for any monitor to sync on the signal. Many probably take more. I doubt switching the signal would work acceptably even if you could send one complete frame to one monitor then the next to another monitor then back again. But unless the switching is synchronized with the video signal you will loose a frame each time you switch. I suggest you put something together to rapidly drop and recover the signal to one monitor to verify that the whole idea will work with a specific monitor. I am very sceptical. Switching the signal without all kinds of signal bounce (as with a button, switch or relay) isn't trivial, there might be an IC for the task though. You probably only need to switch the horiz and vertical sync signals for VGA. The monitor will defiantly notice a lost signal. The LCD controller needs to know where in the data stream that the current pixel is when it is delivered to know what pixel on the screen to set. I don't think most LCDs buffer the frame, there is no need. What could work is using an FPGA like the Xilinx Spartan III (I think this has enough power) on a custom circuit board feed by a dual-link dvi (more expensive card) with single link DVI outputs. But you will have to develop Verilog or VHDL code to decode part of the DVI signal produce an appropriate clock for each output, buffer each video line and shift it out to each output appropriately. This is a good month project to prototype for someone who knows what they are doing and has all the right equipment. The Matrox Graphics eXpansion Modules are basically this, but the price tag is over $300. I have considered developing such devices but I would never sell a 1 to 6 head DVI line buffering splitter for less than $150 (assuming I could sell over 10,000 units), nobody else will either. You could only drive 4 1280x1...@60hz panels from one dual link DVI port. You either have to reduce the res/refresh rate or have a device that buffers the whole frame, and that will be more expensive. Even with this the current Xserver can't be setup to have multiple independent displays on one monitor. Maybe this will change one day. A video splitter that actually works well is a significant design project for one person and easily justify 6 credit hours of design class credits for an electrical engineer major. As the Matrox product proves it can be done. Packing a system with a bunch of PCI video cards really is your best bet. I would look harder for those cards. Someone probably has a bunch laying around they would be happy to sell for little or nothing. Check around campus or other companies, or computer parts auctions. I have 2 or 3 on a shelf somewhere. But the legacy VGA arbiter problem might make the whole thing not work http://www.x.org/wiki/VgaArbiter LCD's aren't exactly cheap. If you where building this new, the total LCD cost would probably be more than the system cost for a 6 display system. Probably total new cost of about $1200 for 6 displays. Can you procure the whole thing new? I expect you could find a single vendor that will sell the whole thing. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
