XDMCP over SSH - a better idea (hopefully)
Hi, Sorry I sent this email to xorg-devel but I realized that this should be a feature discussion, not yet a development discussion... So I resend it here. Recently I want to implement XDMCP over SSH feature when doing my project. I've done some research and understand that "XDMCP uses UDP that natively cannot be tunnelled over SSH", however there's a well-known workaound: LOCAL$ ssh -X REMOTE Xephyr :1 -query localhost which query XDMCP in a remote Xephyr, then to tunnel the Xephyr window using X11 forwarding. However this is not working good enough for me since (1) I don't want to ask users to install Xnest or Xephyr on SSH server (2) Somehow the tunnelled Xephyr window won't recognize -parent argument to embed into my app - it always create a top-level window; well, this could be another bug but I don't want to waste my time investigating on this, since now I came up with a better solution. I would like to implement a new binary, let's temporarily call it "xdmcp-bin". It will fully implement the XDMCP protocol and talks to any Display Manager; however, instead of creating a new X server like Xephyr or Xnest does, it simply ask the Display Manager to connect to an existing one (usually this is the X server that $DISPLAY is pointing to - like any other X clients). So here comes the real thing. :) A typical XDMCP over SSH senario would be: LOCAL$ Xephyr :1 (or even X :1, whatever that creates a new X server) LOCAL$ export DISPLAY=:1 LOCAL$ ssh -X REMOTE xdmcp-bin -query localhost What happen in the third line is that, "xdmcp-bin" runs on REMOTE, query its Display Manager to create a new session and connect to "xdmcp-bin"'s DISPLAY environment, which is a X11 tunnel that connects back to :1 at LOCAL. You know what should happen next: we tunnel XDMCP session. I am totally new to X.org development. I would like to get your comments before I get started with this new feature. Thanks, Vic ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xvinfo "short" mode
Cleaning out my folder of patches to review, and finally pushed this one to master since no one else had yet. Sorry for taking so long. -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering Arthur Huillet wrote: > Hello, > > please find attached a patch to xvinfo that adds the -short commandline > option. > The purpose of this option is to display only critical information in a > compact manner. > > Examples of output: > http://people.freedesktop.org/~ahuillet/xvinfo_orig - normal output > http://people.freedesktop.org/~ahuillet/xvinfo_short - short output > > It doesn't break anything (as far as I can tell :p), so it doesn't hurt to > apply it. > It is expected to be useful to anyone who wants to have information about his > Xv setup (for > example, what attributes are available), without unneeded details. > > Note that the manual page was updated as well. > > > > > ___ > 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: Intel i915 / GEM throttling / 2.6.31-rc
On Mon, 2009-08-03 at 17:20 +0200, Sven Arvidsson wrote: > On Mon, 2009-08-03 at 16:58 +0200, Michał Kazior wrote: > > Since the inclusion of a GEM throttling commit [1] to the 2.6.31 > > release candidate I started to have serious issues using 3D > > acceleration. > > > [...] > > > > Are you guys aware of this issue ? Any other thoughts ? > > Eric Anholt posted a patch on the mesa3d-dev list, which seems to be > made for use with the new throttling behaviour. I don't think it has > been commited yet though? > > http://www.nabble.com/-PATCH--intel%3A-Use-a-new-DRI2-extension-to-throttle-the-number-of-outstanding-frames.-td24609475.html Yeah, review was "you're working too hard, do this simpler thing." I hadn't gotten around to writing it yet. commit 0828579a658af01a64b5e699175dc9bbbedcd685 Author: Eric Anholt Date: Tue Jul 21 11:23:18 2009 -0700 intel: Wait on the last swapbuffers to complete before queuing a new one. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xmag 1.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (1): Version bump: 1.0.3 Jeremy Huddleston (1): Build fix for file systems that are not case sensitive Julien Cristau (2): allow build outside of source tree xaw8 is gone, use xaw7 Paulo Cesar Pereira de Andrade (2): Properly handle multiple depth windows. Correct problems in make distcheck. git tag: xmag-1.0.3 http://xorg.freedesktop.org/archive/individual/app/xmag-1.0.3.tar.bz2 MD5: 32f7ed4c089365cadb9382f6fbd750a9 SHA1: 1acbc1ccdcd0399b62ad6e96a47021c00dcfde7d http://xorg.freedesktop.org/archive/individual/app/xmag-1.0.3.tar.gz MD5: 8afd35df69a2fdb7275debb92c1eb6f8 SHA1: 56e44b3dee3ca961ec99666d97b15455d5919523 - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp3Q5IACgkQovueCB8tEw75GACfSanXDG+dOmT/xZncNwR0gRg2 Tr8AnilEdowUEl/GpVI927rFtDNPDmcT =ehwz -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xrx 1.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (3): Fix PLUGIN_CFLAGS setting without firefox-plugin.pc & mozilla-plugin.pc Make plugin build compatible with Firefox 3.1 renaming of npupp.h Version 1.0.3 James Cloos (1): xaw8 is gone, use xaw7 Paulo Cesar Pereira de Andrade (1): Correct make distcheck and most sparse warnings. git tag: xrx-1.0.3 http://xorg.freedesktop.org/archive/individual/app/xrx-1.0.3.tar.bz2 MD5: c121945afcfc84e99af17158fda68be9 SHA1: 76265c2046b637701c4b61cbfe532ed542640950 http://xorg.freedesktop.org/archive/individual/app/xrx-1.0.3.tar.gz MD5: d59f9f9b58fea0bcfa816389a214d902 SHA1: faf2635b89f1d96896b0de037926ea075d88dd03 - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp3Qa8ACgkQovueCB8tEw4XjACcDIda/F5rZRkcLdUdaQK4ezJ7 gfcAn1twYJwqaHBWf+h2iaFA8DAe0dXt =KLRE -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X software to create a demo
Is there any easy way to create a demo in X? I just something to play back a series of events (moving windows around, spinning the cube, etc.) in a loop on a current distro. I haven't been able to find anything that isn't broken current X bits yet. Thanks, Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel i915 / GEM throttling / 2.6.31-rc
On Mon, 2009-08-03 at 16:58 +0200, Michał Kazior wrote: > Since the inclusion of a GEM throttling commit [1] to the 2.6.31 > release candidate I started to have serious issues using 3D > acceleration. > [...] > > Are you guys aware of this issue ? Any other thoughts ? Eric Anholt posted a patch on the mesa3d-dev list, which seems to be made for use with the new throttling behaviour. I don't think it has been commited yet though? http://www.nabble.com/-PATCH--intel%3A-Use-a-new-DRI2-extension-to-throttle-the-number-of-outstanding-frames.-td24609475.html -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Fix focus follow mouse usability problem
Hi, if focus follows mouse is used, all window managers I know of have a serious usability problem: a window is focused as soon as it is entered. Even if the pointer is just passes a window while moved between two other windows.. In this case I would expect no focus change. The window should be focused, as soon as the pointer stops over the window. My question is, if it is even possible for a WM to detect, that the pointer stopped. If it is, I can file a wishlist bug for my WM du jour. Though I fear it might not be possible, because the WM would have to grab the pointer and accurately track it's movement. If it's not possible yet, are there plans to implement such functionality in the X server? Like sending an event whenever the pointer stops? The current behaviour is so annoying, because it can have side-effects, when a window gets the focus: - It gets moved up in the list of recently focused windows. Thus if you switch back and forth between two windows with the keyboard and then use the mouse once to switch, you might move over a third or a fourth window. Now you can't simply switch back with the keyboard. You have to skip the third and the fourth window, which you didn't even intend to focus, in the first place. - Broken GUI designs, like GIMP's are unusable. The tool windows apply to the currently focused main window. You might not be able to reach a tool window without moving over another main window. - Windows might remove their urgent flag, as soon as they are focused. Again, this happens, whether or not the focus was intended. Btw., I don't regard delayed focus/raise as a solution. Cheers, harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Intel i915 / GEM throttling / 2.6.31-rc
Hello, Since the inclusion of a GEM throttling commit [1] to the 2.6.31 release candidate I started to have serious issues using 3D acceleration. 3D Applications which are rather simple tend to render themselves in bursts (i.e. shows a dozen of frames and then freezes for a split of a second; repeat). I've filed a bug at kernel bug [2], but now I'm starting to think it might be (also) xserver issue. Recently I noticed a detail which led me here. Stepmania [3] is one of those suffering applications. The interesting part I noticed is that it can render perfectly fine when the game window does not have keyboard focus. If it regains the focus/input - it starts to render in those bursts again. Quake3-demo and glxgears on the other hand render in bursts regardless of the input/focus. It doesn't seem to be WM related too. I thought it might an unintentional sync to the swap or something, but the relation to keyboard focus makes it kind of.. illogical ? Are you guys aware of this issue ? Any other thoughts ? Regards, Michał Kazior. [1]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb [2]: http://bugzilla.kernel.org/show_bug.cgi?id=13713 [3]: http://www.stepmania.com/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
touchscreens in multiscreen setups
Hi, How are touchscreens in multiscreen setups supposed to work nowadays? The issue with touchscreens is that their input events have to be transformed according to configuration of the screen they are physically connected to. For a concrete example, I have a dual screen setup with nextwindow USB (HID) touchscreens. This used to work nicely with the evtouch driver, where you could configure each touchscreen to bind to a specific screen number in xorg.conf, which evtouch would then use to deliver the input events transformed to that screen. Now, with xrandr instead of Xinerama there is only one screen and the above doesn't work (the coordinates gets scaled to the entire screen instead of the individual outputs). What is the suggested solution for this? Add randr output tracking to evtouch or should evdev handle this instead? -- Bye, Peter Korsgaard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
