Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Wed, Dec 02, 2009 at 07:56:17PM -0800, Keith Packard wrote: > On Thu, 3 Dec 2009 13:44:59 +1000, Peter Hutterer > wrote: > > > You'd need to patch this into every extension though. > > Sure, let's at least fix Xinput then; it's the only one changing the > number of events on a regular basis anyway. Heh. not anymore, it's XGE all the way down. Cheers, Peter > But, the patch to make Xlib not smash other extension events is a good > plan too. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xorg-server 1.7.3
The third stable update to the X server 1.7 is now available. As announced [1], 1.7.2 had two major issues, one being a build break, the other one being a ABI incompatibility. This update addresses both of these issues. Many thanks to Aaron and Gaetan for the fixes and Dan and Julien for the reviews. Users of any previous 1.7.x release are encouraged to update to 1.7.3 instead of 1.7.2. Again, my apologies for any inconveniences. Since only two patches went into this release, I'm keeping the original timetable for 1.7.4. Looking at the calendar that means that 1.7.3.902 and 1.7.4 would fall on Christmas Day and New Year's day, respectively. They may be delayed by a reasonable amount of time. Cheers, Peter [1] http://lists.freedesktop.org/archives/xorg-announce/2009-November/001202.html Aaron Plattner (1): Restore ABI by reintroducing the "is_src" paramter to image_from_pict. Gaetan Nadon (1): configure.ac: error while checking for XDMXCONFIG_DEP Peter Hutterer (1): xserver 1.7.3 git tag: xorg-server-1.7.3 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.7.3.tar.bz2 MD5: 4c63b22cad9ed8ae8b86561f0f92c327 xorg-server-1.7.3.tar.bz2 SHA1: db04e090a22f73f5a7137b06eb7952ba10272c7d xorg-server-1.7.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.7.3.tar.gz MD5: d37ca763663eec0b8bc1d544c4943a90 xorg-server-1.7.3.tar.gz SHA1: bbf08ab3a8deddfa2acf6712503c3f38bd4ad6d3 xorg-server-1.7.3.tar.gz pgpRozeTBqRX7.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Thu, 3 Dec 2009 13:44:59 +1000, Peter Hutterer wrote: > You'd need to patch this into every extension though. Sure, let's at least fix Xinput then; it's the only one changing the number of events on a regular basis anyway. But, the patch to make Xlib not smash other extension events is a good plan too. -- keith.pack...@intel.com pgpqnQnP7JGXU.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Wed, Dec 02, 2009 at 07:15:57PM -0800, Keith Packard wrote: > On Thu, 26 Nov 2009 11:45:39 +1000, Peter Hutterer > wrote: > > On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote: > > > Attached is an attempt of a fix to libXext. There's not a lot of > > wriggle-room, the APIs are quite restrictive and we can't pass a great deal > > of information around. Additionally, the library has no way of knowing how > > many events a given extension has, it's pure guesswork (or compiled into the > > library). > > Why can't the library know? Presumably it needs to support all of these > extension versions, or it won't actually work at all (and should fail to > initialize itself). > > Is it that the extension version isn't known at this point? Pretty much, yes. For example, in libXrandr, the path is XRRFindDisplay -> XextAddDisplay -> XInitExtension -> XQueryExtension libXrandr libXext libX11libX11 XextAddDisplay gets the number of events passed in and it's hardcoded. Now, you could probably get around that by changing XRRFindDisplay to issue an XRRQueryVersion before XextAddDisplay and adjusting the number of events based on the returned version. You'd need to patch this into every extension though. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch
On Thu, 26 Nov 2009 11:45:39 +1000, Peter Hutterer wrote: > On Wed, Nov 25, 2009 at 04:42:59PM -0500, Nathan Kidd wrote: > Attached is an attempt of a fix to libXext. There's not a lot of > wriggle-room, the APIs are quite restrictive and we can't pass a great deal > of information around. Additionally, the library has no way of knowing how > many events a given extension has, it's pure guesswork (or compiled into the > library). Why can't the library know? Presumably it needs to support all of these extension versions, or it won't actually work at all (and should fail to initialize itself). Is it that the extension version isn't known at this point? -- keith.pack...@intel.com pgpCcoNCmVIi1.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH v2] Don't smash the event_vec if num_events differs between lib and server.
On Fri, Nov 27, 2009 at 10:39:50 +0100, Julien Cristau wrote: > On Fri, Nov 27, 2009 at 13:48:38 +1000, Peter Hutterer wrote: > > > If the library extension thinks there's more events to an extension than the > > server actually has, the event_vec for the overlapping range can get > > overwritten. This depends on the initialization order of the libraries. > > > > Reported-by: Nathan Kidd > > Signed-off-by: Peter Hutterer > > Reviewed-by: Julien Cristau > Sigh. Now that I look again... The ext_handlers[] array is shared by all possible Displays you could pass in. An app using more than one will get broken data in there. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Adam Jackson wrote: > This has been my plan for a while. Most of the DDC/CI controls map well > to RANDR properties. I'm not sure what's implied by "RANDR property" :- since monitors vary widely in terms of what DDC/CI they support, I suspect that at a basic level this needs to be a communication channel. (ie. a primary motivator from my perspective is to access things like display lookup tables, transform matrices etc. which are not standardized). A user level or X11 server library on top of the basic capability could then pretty it all up in terms of accessing standard controls, and allow for particular model knowledge and quirks. cheers, Graeme Gill. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
Hi, On Wed, Dec 02, 2009 at 03:07:50PM +0100, Yann Droneaud wrote: > Did you know you're writing to a public mailing list ? So the content of > your mail is not going to be "confidential" and "disclosure, > distribution [and] copying" is going to happen. In fact is already > happened. > > This message is disclosed in mailing list archives, like here > http://lists.freedesktop.org/archives/xorg/2009-December/048266.html > > The license (it seems be a licence: it uses the same wording and sounds > like) seems not adapted for Internet days ... > > I hope the SNCF (Société National des Chemins de Fer) is not going to > enforce it ... > > For all: is there a policy about it ? No, there's no policy about it because the reality is, as others have said, that people are often forced to use their corporate mail system which adds that disclaimer[0], and they have no say in it. Banning them from the list would add an arbitrary barrier and be quite petty. Besides, I didn't even notice that disclaimer (years of skipping practice), yet I _definitely_ noticed this subthread, and spent a lot longer reading it than I've ever been distracted by a disclaimer. So yeah, the policy is pretty much 'censor with your eyes'. Cheers, Daniel [0]: Or maybe something like Nokia's, which prepends 'ext' to the name of every external sender: you'll notice that on the list from time to time. pgpF25DDyKVed.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
Hi, On Sat, Nov 28, 2009 at 01:25:08AM +0100, olafbuddenha...@gmx.net wrote: > On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: > > If you don't want a session manager or you prefer a different desktop > > environment - you're on your own. > > Let me remind you that GNOME is not an operating system. It is just a > frontend. > > It is nice if it provides a nice shiny tool to configure stuff; but it > has no business *storing*, and *applying* such settings, which don't > really have anything to do with GNOME at all. These should be pushed > down to some generic infrastructure, which is not desktop-specific, and > in fact not X-specific at all. > > Unfortunately, it appears that such a generic session-aware hotplug > infrastructure is yet to be invented... I'm sure both GNOME and KDE would love you for writing one that both had no complaints with, and was perfectly integrated with both. And Xfce. And Moblin. And Maemo. And fvwm2, and fluxbox, and my 'sudo Xorg :0 -noreset &| ~/bin/de &|'. Looking forward to it! :) Cheers, Daniel pgpWm7vowqlqr.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xorg, Xvfb, ImageMagick - then beat your head against your desk!
I'm launching this with apache, by hitting a php test page on ionisis.com, and that php page calls the exec command which is supposed to launch a virtual x (Xvfb), and then a firefox instance, and sleeps for 4 seconds, and then uses import to grab a screenshot of the website. I've got this all in a shell script, and if i exec the shell script from the console, as a USER (me, or root), on my machine OR my server, all is fine; but when i have APACHE exec it via php "exec", i keep running into various problems. I've got ALMOST all of it sorted out right now . I had to create a /var/www/.gnome/ and a /var/www/.gnome_private/ and a /var/www/.gnome/accels directory that eliminated a LOT of errors, and now i actually get a screenshot from it when using apache! However it is an EMPTY X screen, with the old-school cross hatch background, and no firefox or import. Like i said, i've tracked down a lot of the errors, and eliminated them. Here are the latest errors (in total): [^v^] cat /var/log/httpd/error_log | tail xauth: creating new authority file /tmp/xvfb_1_at_a_time _XSERVTransmkdir: ERROR: (l)stat failed for /tmp/.X11-unix (13) _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 13 _XSERVTransMakeAllCOTSServerListeners: failed to create listener for unix Xlib: extension "RANDR" missing on display ":66.0". firefox: no process killed I'm not sure why it's trying to create that directory when it is already there; furthermore, why it is trying to create it when run by APACHE, but not when run by a USER... BTW, i've never used a mailing list before... Thanx! -- Vector Thorn, Ionisis 513-549-5040 http://Ionisis.com http://LinuxIntro.com http://TheReformProject.com http://eInformationManager.com http://eInformationOrganizer.com http://InHomeHealthCareAgency.com All websites are under development ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
Alan Coopersmith wrote: > misunderstanding. (My employer on the other hand, requires us not to > automatically label everything as confidential, since that just causes people > to assume nothing really is, and destroys all value of true confidential > labels.) I'm amazed by the sheer amount of common sense in that policy! Is Sun hiring? ;) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Reply to thread 'Getting S-Video out working with X on an 8800GS'
I tried your suggestion but got the usual black TV screen when I start X. I also tried adding three lines: Option "TVOutFormat" "SVIDEO" Option "TVStandard" "NTSC-M" Option "ConnectedMonitor" "TV" But that too gave just a black screen. I have x11vnc configured to run so it always runs when X is running (for this user). I can connect via vnc and I can see in nvidia-settings that TV-0 is detected and running @ 800x600, yet the TV itself is black as soon as X loads...??? I also don't see anything bad in my /var/log/Xorg.0.log X.Org X Server 1.7.2 Release Date: 2009-11-27 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.31-ARCH i686 Current Operating System: Linux lightning 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:48:17 CET 2009 i686 Kernel command line: root=/dev/sda2 ro quiet vga=773 Build Date: 30 November 2009 09:10:33AM Current version of pixman: 0.16.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec 2 14:32:28 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Layout0" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Device0" (**) |-->Input Device "Keyboard0" (**) |-->Input Device "Mouse0" (==) Automatically adding devices (==) Automatically enabling devices (==) FontPath set to: /usr/share/fonts/misc, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/TTF, /usr/share/fonts/Type1 (==) ModulePath set to "/usr/lib/xorg/modules" (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Keyboard0 (WW) Disabling Mouse0 (II) Loader magic: 0x81e6100 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) using VT number 8 (--) PCI:*(0:2:0:0) 10de:06e4:: nVidia Corporation G98 [GeForce 8400 GS] rev 161, Mem @ 0xc200/16777216, 0xb000/268435456, 0xc000/33554432, I/O @ 0xa000/128, BIOS @ 0x/131072 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.2, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 190.42 Tue Oct 20 20:55:08 PDT 2009 (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.2, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.2, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.2, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "nvidia" (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so (II) Module nvidia: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Video Driver (II) NVIDIA dlloader X Driver 190.42 Tue Oct 20 20:26:00 PDT 2009 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs (II) Primary Device is: PCI 0...@00:00:0 (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules/libfb.so (II
Re: client side ddc/ci
On Wed, 2009-12-02 at 19:07 +1000, Dave Airlie wrote: > > > > how would one talk with a monitor over DDC/CI on a user side, non root > > application. I would like to do monitor gamma curves I/O, EDID polling and > > other non standard communication. > > > > The /dev/i2c-xxx device nodes are root access only on my system. I can > > chmod them with o+rw, but thats shurely not the general solution. > > > > What is a good place to start with in Xorg? > > > > I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the > > server. Is already one of those APIs exposed? > > > > As I understand, the root windows or xrandr output EDID atom is a one time > > thing and too static for my needs. > > You'd need to add protocol for the client side apps to talk to the X server,. > > you could possibly do this with xrandr properties or extending xrandr, > then drivers would have to talk to the i2c via X i2c or kernel i2c in kms > case. This has been my plan for a while. Most of the DDC/CI controls map well to RANDR properties. The major blocker for this before was that CI is _slow_. Way too slow to do in-server, since you block all your other clients. With KMS we could reasonably expose this all as DRM properties and do it async. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
And thus marks the last time I attempt to be sassy on my Droid. But as I was saying, the Generic Userspace Configuration Kit. If we're going to add a Session Hotplug Infrastructure Tasklet, which is desktop-agnostic, in order to configure the X server across multiple platforms, you're going to need a Generic Userspace Configuration Kit to talk to the kernel, since that's where the devices live. Being desktop-aware has a lot of benefits, mostly in the realm of policy control and convenience, and letting the DE configure things is not as bad as, say, having GNOME-specific code in the server. On Wed, Dec 2, 2009 at 9:34 AM, Corbin Simpson wrote: > You're right. We need a Generic Userspace Configuration Kit, which could > talk to the Session Hotplug Infrastucture > > Posting from a mobile, pardon my terseness. ~ C. > > On Dec 2, 2009 5:09 AM, wrote: > > Hi, > > On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: > If you > don't want a session mana... > > Let me remind you that GNOME is not an operating system. It is just a > frontend. > > It is nice if it provides a nice shiny tool to configure stuff; but it > has no business *storing*, and *applying* such settings, which don't > really have anything to do with GNOME at all. These should be pushed > down to some generic infrastructure, which is not desktop-specific, and > in fact not X-specific at all. > > Unfortunately, it appears that such a generic session-aware hotplug > infrastructure is yet to be invented... > > -antrik- > > ___ xorg mailing list > xorg@lists.freedesktop.org http://... -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
You're right. We need a Generic Userspace Configuration Kit, which could talk to the Session Hotplug Infrastucture Posting from a mobile, pardon my terseness. ~ C. On Dec 2, 2009 5:09 AM, wrote: Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: > If you don't want a session mana... Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
> > For all: is there a policy about it ? > > Ignore it. If it really bugs you add it to your spam filter matches and they'll never trouble you again. They have at least kept it shorter than some of the gems attached by companies and used the word "please" ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
On Wed, Dec 02, 2009 at 07:47:01AM -0800, Alan Coopersmith wrote: > Sarbanes-Oxley (SOX) does not require it, though your company's implementation > of SOX compliance policies may have chosen to inflict that on you due to > misunderstanding. (My employer on the other hand, requires us not to > automatically label everything as confidential, since that just causes people > to assume nothing really is, and destroys all value of true confidential > labels.) Ok, I beleive you, I don't even know too much about "SOX" just these three letters :) But still, as an employee, I can't complain too much, and I guess this can be true for other situations as well, if the company decides this way, I can't do anything to mail without these disclaimers. Just using another mail infrastructure to do my non-company related (private) messaging which of course is a nice idea anyway too :) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
On Wed, Dec 2, 2009 at 4:39 AM, Kai-Uwe Behrmann wrote: > Am 02.12.09, 10:17 +0100 schrieb Xavier Bestel: >> On Wed, 2009-12-02 at 19:07 +1000, Dave Airlie wrote: how would one talk with a monitor over DDC/CI on a user side, non root application. I would like to do monitor gamma curves I/O, EDID polling and other non standard communication. The /dev/i2c-xxx device nodes are root access only on my system. I can chmod them with o+rw, but thats shurely not the general solution. What is a good place to start with in Xorg? I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the server. Is already one of those APIs exposed? As I understand, the root windows or xrandr output EDID atom is a one time thing and too static for my needs. >>> >>> You'd need to add protocol for the client side apps to talk to the X >>> server,. >>> >>> you could possibly do this with xrandr properties or extending xrandr, >>> then drivers would have to talk to the i2c via X i2c or kernel i2c in kms >>> case. >> >> Have a look at http://ddccontrol.sourceforge.net/ for a working >> implementation that bypasses the X server (although as says Dave, going >> through Xrandr looks like the right thing to do). > > ddccontrol uses /dev/i2c-xxx, so the problem of non root access remains > with that library. Otherwise it seems very fine. One problem with /dev/i2c-xxx, at least on radeon, is that the gpio lines need to be masked and unmasked for sw use before and after an i2c transaction. The driver takes care of this internally when doing i2c, but it's not done if you use the /dev interface. I plan to add a radeon i2c algo that takes care of this but I haven't gotten around to it yet. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
Gábor Lénárt wrote: > I wouldn't be able to avoid that either. And I think it's a must everywhere > if there is something involved with the "SOX". At least I was told that > this is the reason in our case. Sorry for the off-topic :) Sarbanes-Oxley (SOX) does not require it, though your company's implementation of SOX compliance policies may have chosen to inflict that on you due to misunderstanding. (My employer on the other hand, requires us not to automatically label everything as confidential, since that just causes people to assume nothing really is, and destroys all value of true confidential labels.) -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
On Wed, 02 Dec 2009 15:07:50 +0100 Yann Droneaud wrote: > Did you know you're writing to a public mailing list ? So the content of > your mail is not going to be "confidential" and "disclosure, > distribution [and] copying" is going to happen. In fact is already > happened. > > This message is disclosed in mailing list archives, like here > http://lists.freedesktop.org/archives/xorg/2009-December/048266.html > > The license (it seems be a licence: it uses the same wording and sounds > like) seems not adapted for Internet days ... > > I hope the SNCF (Société National des Chemins de Fer) is not going to > enforce it ... I don't know how this is handled in France, but in Switzerland, such legal mambo jambo is invalid as the recipient has not agreed to it. I assume from my knowledge of EU law, that the same is true for EU countries. Beside, you can definitly not enforce something that you violated yourself (ie telling not to distribute something that you alread published to a public platform yourself). At least this is true in countries that do not start with U and end with SA. > For all: is there a policy about it ? Ignore it. Attila Kinali -- If you want to walk fast, walk alone. If you want to walk far, walk together. -- African proverb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] e-mail license
On Wed, Dec 02, 2009 at 03:07:50PM +0100, Yann Droneaud wrote: > Did you know you're writing to a public mailing list ? So the content of > your mail is not going to be "confidential" and "disclosure, > distribution [and] copying" is going to happen. In fact is already > happened. Many company has the policy, that outgoing mails are "disclaimerized" and you can't avoid it, since the disclaimer is attached by the outgoing mail server itself (the MUA itself does not even know about that). For example we have this situation as well. It's another question that I am not using the company mail system for mailing to this mail list, but if my company would be interested in XOrg development, and I should use that mail account, I wouldn't be able to avoid that either. And I think it's a must everywhere if there is something involved with the "SOX". At least I was told that this is the reason in our case. Sorry for the off-topic :) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Force destroy Widget
Le mercredi 02 décembre 2009 à 10:41 +0100, LALLIER Cedric (EXT TEAMLOG) a écrit : > Hi, > I'm not an Xt developer > > I don’t understand why the old widget is not destroyed. As explained in the XtDestroyWidget() manpage, destroy is a two phase operation, eg. the destroy operation is "really" done at the end of XtDispatchEvent(). Widget name are not unique, so after the second call to XtVaCreateManagedWidget(), two "test_form" widget exists. XtNameToWidget() could return any of the child of Root_wid that match the name "test_form". BTW, having XtNameToWidget() returning a pending deleted widget is not something I found to be useful. Regards -- Yann Droneaud ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[OT] e-mail license
Hi, Le mercredi 02 décembre 2009 à 10:41 +0100, LALLIER Cedric (EXT TEAMLOG) a écrit : > --- > Ce message et toutes les pièces jointes sont établis à l'intention exclusive > de ses destinataires > et sont confidentiels. L'intégrité de ce message n'étant pas assurée sur > Internet, la SNCF ne peut > être tenue responsable des altérations qui pourraient se produire sur son > contenu. Toute > publication, utilisation, reproduction, ou diffusion, même partielle, non > autorisée préalablement > par la SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de > ce message, > merci d'en avertir immédiatement l'expéditeur et de le détruire. > --- > This message and any attachments are intended solely for the addressees and > are confidential. > SNCF may not be held responsible for their contents whose accuracy and > completeness cannot be > guaranteed over the Internet. Unauthorized use, disclosure, distribution, > copying, or any part > thereof is strictly prohibited. If you are not the intended recipient of this > message, please > notify the sender immediately and delete it. Did you know you're writing to a public mailing list ? So the content of your mail is not going to be "confidential" and "disclosure, distribution [and] copying" is going to happen. In fact is already happened. This message is disclosed in mailing list archives, like here http://lists.freedesktop.org/archives/xorg/2009-December/048266.html The license (it seems be a licence: it uses the same wording and sounds like) seems not adapted for Internet days ... I hope the SNCF (Société National des Chemins de Fer) is not going to enforce it ... For all: is there a policy about it ? Regards. -- Yann Droneaud ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Force destroy Widget
"LALLIER Cedric (EXT TEAMLOG)"
writes:
>Hi,
>
>
>I don't understand why the old widget is not destroyed. How can I force
>the destruction?
>
>
>/* Create widget */
>
>wid_form = XtVaCreateManagedWidget("test_form", xmFormWidgetClass,
>Root_wid, NULL);
>
>printf("create wid_form : %p\n", wid_form);
>
>
>/* Destroy widget */
>
>XtDestroyWidget(wid_form);
>
>printf("destroy wid_form : %p\n", wid_form);
>
>
>/* Re create widget */
>
>wid_form_element_rame = XtVaCreateManagedWidget("test_form",
>xmFormWidgetClass, Root_wid, NULL);
>
>printf("recreate wid_form : %p\n", wid_form);
>
>
>/* Call widget */
>
>wid_form = XtNameToWidget(Root_wid, "test_form");
>
>printf("call wid_form : %p\n", wid_form);
>
>
>
>Result :
>
>
>
>create wid_form : 0x8a6be28
>
>destroy wid_form : (nill)
>
>recreate wid_form : 0x8a61ec8
>
>call wid_form : 0x8a6be28 ß Why this is the old widget
You could try this code:
void * p = malloc(100);
printf("p: %p\n", p);
free(p);
p = malloc(100);
printf("p: %p\n", p);
free(p);
I think you will usually find that the two lines print the same address.
Would you still wonder why the first "free(p)" did not destroy the
pointer?
I suspect what you do in your code is largely equivalent to this
example: after freeing a block of memory you immediately allocate
another block of the same size. Many memory allocators (particularly
those based on doug lea's malloc) will give you back the block you just
freed.
eirik
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput: Do I want xorg.conf? Do I want hal? Do I want udev?
Hi, On Fri, Nov 27, 2009 at 09:55:22AM +1000, Peter Hutterer wrote: > If you don't want a session manager or you prefer a different desktop > environment - you're on your own. Let me remind you that GNOME is not an operating system. It is just a frontend. It is nice if it provides a nice shiny tool to configure stuff; but it has no business *storing*, and *applying* such settings, which don't really have anything to do with GNOME at all. These should be pushed down to some generic infrastructure, which is not desktop-specific, and in fact not X-specific at all. Unfortunately, it appears that such a generic session-aware hotplug infrastructure is yet to be invented... -antrik- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Am 02.12.09, 23:41 +1100 schrieb Graeme Gill: > Kai-Uwe Behrmann wrote: >> No. The used ookala-mcf just searches to find some EDID in the >> communication and then talks to a EDID containing device. See DevI2c.cpp >> around line 153. Ookala::DevI2c::enumerate() > > So in theory a correspondence could be fudged by searching all the i2c devices > for those that look like a display, read the EDID and then try and match > it against the ones in the X11 Properties. Is this idea likely to be wrecked > by various quirks being "fixed" the EDID X11 property though ? I am not a native english reader and speacker. But if you search for a correspondense between a i2c device and a Xorg monitor by the help of the EDID properties, I think it could work. Still running profiling routines as super user is not a general solution for most computers. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Kai-Uwe Behrmann wrote: > No. The used ookala-mcf just searches to find some EDID in the > communication and then talks to a EDID containing device. See DevI2c.cpp > around line 153. Ookala::DevI2c::enumerate() So in theory a correspondence could be fudged by searching all the i2c devices for those that look like a display, read the EDID and then try and match it against the ones in the X11 Properties. Is this idea likely to be wrecked by various quirks being "fixed" the EDID X11 property though ? Graeme Gill. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Am 02.12.09, 20:59 +1100 schrieb Graeme Gill: > Kai-Uwe Behrmann wrote: >> ddccontrol uses /dev/i2c-xxx, so the problem of non root access remains >> with that library. Otherwise it seems very fine. > > Is there a mechanism to associate the /dev/i2c-xxx with the matching > display though ? No. The used ookala-mcf just searches to find some EDID in the communication and then talks to a EDID containing device. See DevI2c.cpp around line 153. Ookala::DevI2c::enumerate() kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
On Wed, 2009-12-02 at 20:59 +1100, Graeme Gill wrote: > Kai-Uwe Behrmann wrote: > > ddccontrol uses /dev/i2c-xxx, so the problem of non root access remains > > with that library. Otherwise it seems very fine. > > Is there a mechanism to associate the /dev/i2c-xxx with the matching > display though ? The X server already kind of does that when it gets EDID by DDC. One more argument for X server (by way of KMS I think) integration. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Kai-Uwe Behrmann wrote: > ddccontrol uses /dev/i2c-xxx, so the problem of non root access remains > with that library. Otherwise it seems very fine. Is there a mechanism to associate the /dev/i2c-xxx with the matching display though ? Graeme Gill. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Force destroy Widget
Hi,
I don't understand why the old widget is not destroyed. How can I force the
destruction?
/* Create widget */
wid_form = XtVaCreateManagedWidget("test_form", xmFormWidgetClass, Root_wid,
NULL);
printf("create wid_form : %p\n", wid_form);
/* Destroy widget */
XtDestroyWidget(wid_form);
printf("destroy wid_form : %p\n", wid_form);
/* Re create widget */
wid_form_element_rame = XtVaCreateManagedWidget("test_form", xmFormWidgetClass,
Root_wid, NULL);
printf("recreate wid_form : %p\n", wid_form);
/* Call widget */
wid_form = XtNameToWidget(Root_wid, "test_form");
printf("call wid_form : %p\n", wid_form);
Result :
create wid_form : 0x8a6be28
destroy wid_form : (nill)
recreate wid_form : 0x8a61ec8
call wid_form : 0x8a6be28 <-- Why this is the old widget
Thx
Cédric
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations
qui pourraient se produire sur son contenu. Toute publication, utilisation,
reproduction, ou diffusion, même partielle, non autorisée préalablement par la
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are
confidential. SNCF may not be held responsible for their contents whose
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized
use, disclosure, distribution, copying, or any part thereof is strictly
prohibited. If you are not the intended recipient of this message, please
notify the sender immediately and delete it.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Am 02.12.09, 10:17 +0100 schrieb Xavier Bestel: > On Wed, 2009-12-02 at 19:07 +1000, Dave Airlie wrote: >>> how would one talk with a monitor over DDC/CI on a user side, non root >>> application. I would like to do monitor gamma curves I/O, EDID polling and >>> other non standard communication. >>> >>> The /dev/i2c-xxx device nodes are root access only on my system. I can >>> chmod them with o+rw, but thats shurely not the general solution. >>> >>> What is a good place to start with in Xorg? >>> >>> I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the >>> server. Is already one of those APIs exposed? >>> >>> As I understand, the root windows or xrandr output EDID atom is a one time >>> thing and too static for my needs. >>> >> >> You'd need to add protocol for the client side apps to talk to the X server,. >> >> you could possibly do this with xrandr properties or extending xrandr, >> then drivers would have to talk to the i2c via X i2c or kernel i2c in kms >> case. > > Have a look at http://ddccontrol.sourceforge.net/ for a working > implementation that bypasses the X server (although as says Dave, going > through Xrandr looks like the right thing to do). ddccontrol uses /dev/i2c-xxx, so the problem of non root access remains with that library. Otherwise it seems very fine. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
Hi, On Wed, 2009-12-02 at 19:07 +1000, Dave Airlie wrote: > > > > how would one talk with a monitor over DDC/CI on a user side, non root > > application. I would like to do monitor gamma curves I/O, EDID polling and > > other non standard communication. > > > > The /dev/i2c-xxx device nodes are root access only on my system. I can > > chmod them with o+rw, but thats shurely not the general solution. > > > > What is a good place to start with in Xorg? > > > > I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the > > server. Is already one of those APIs exposed? > > > > As I understand, the root windows or xrandr output EDID atom is a one time > > thing and too static for my needs. > > > > You'd need to add protocol for the client side apps to talk to the X server,. > > you could possibly do this with xrandr properties or extending xrandr, > then drivers would have to talk to the i2c via X i2c or kernel i2c in kms > case. Have a look at http://ddccontrol.sourceforge.net/ for a working implementation that bypasses the X server (although as says Dave, going through Xrandr looks like the right thing to do). Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: client side ddc/ci
> > how would one talk with a monitor over DDC/CI on a user side, non root > application. I would like to do monitor gamma curves I/O, EDID polling and > other non standard communication. > > The /dev/i2c-xxx device nodes are root access only on my system. I can > chmod them with o+rw, but thats shurely not the general solution. > > What is a good place to start with in Xorg? > > I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the > server. Is already one of those APIs exposed? > > As I understand, the root windows or xrandr output EDID atom is a one time > thing and too static for my needs. > You'd need to add protocol for the client side apps to talk to the X server,. you could possibly do this with xrandr properties or extending xrandr, then drivers would have to talk to the i2c via X i2c or kernel i2c in kms case. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Getting S-Video out working with X on an 8800GS
I have an 8400GS that has an S-Video out and I want to run it connected to a SDTV only (not to a CRT and TV). When I connect the card to my TV via an S-video cable without connecting the monitor at all, I can watch Linux boot on the TV. Problem for me is when I start X. The TV goes blank. If I plug in a CRT monitor, X is being displayed there rather than on the TV. If I have the TV connected and I also connect a CRT monitor, I can get into X just fine. The nvidia-settings program doesn't detect my TV at all. I should say that if I switch out the 8400GS (PCI) for an older 6200 (AGP) everything just works without any modifications to the /etc/X11/xorg.conf at all! I've tried adding many of the suggested lines at the following wiki page, but still, no output to X: http://en.wikibooks.org/wiki/NVidia/TV-OUT Here is the /etc/X11/xorg.conf that works with the 6200 (AGP) but not with the 8400GS (PCI): Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Mouse0" "CorePointer" EndSection Section "Files" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "Unknown" HorizSync 28.0 - 33.0 VertRefresh 43.0 - 72.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor"Monitor0" DefaultDepth24 SubSection "Display" Depth 24 Modes "800x600" EndSubSection EndSection ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
client side ddc/ci
Hello, how would one talk with a monitor over DDC/CI on a user side, non root application. I would like to do monitor gamma curves I/O, EDID polling and other non standard communication. The /dev/i2c-xxx device nodes are root access only on my system. I can chmod them with o+rw, but thats shurely not the general solution. What is a good place to start with in Xorg? I have seen the ddc/XF64DDC.[h,c] and i2c/xf86i2c.[h,c] modules in the server. Is already one of those APIs exposed? As I understand, the root windows or xrandr output EDID atom is a one time thing and too static for my needs. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
