Today's stupid question: remapping AltGr to control?
I have a Dell Mini 9 running Ubuntu 10.04 (xorg-server 2:1.7.6-2ubuntu7). I don't use the AltGr key *ever*, and am really missing having a right Control key. Can I remap AltGr to be a control key? So far I've failed utterly with xmodmap and xkeycaps. Failed xmodmap command: xmodmap -e "keysym Alt_R = Control_L" xkeycaps says that it thinks it's a Control but doesn't have a modifier. Can this actually be done? - d. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with X.org and incompatibilities with in-house software
On 1 March 2010 03:04, Russell Shaw wrote: > Interesting > http://web.archive.org/web/20080413140042/http://people.freedesktop.org/~jg/roadmap.html#mozTocId778727 I put the archive.org link into the Wikipedia article because the original fell off the web. Is there another canonical copy up anywhere? This is a pretty important document. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
On 1 March 2010 01:28, Richard Brown wrote: > Russell Shaw wrote: >> What are you referring to by "Ximage" ? > Ximage extension to the X server. It has been superceded by MIT shared > memory. However, some ancient apps may still use it. It's not clear that *anyone* ever manage to use it successfully. http://en.wikipedia.org/wiki/X_Image_Extension - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Dual-head config broke with update to 1.4.2
On 16 February 2010 17:30, Alex Deucher wrote: > I guess rather than implementing a modern dynamic window system with > support for the full capabilities of the hardware we should continue > bend over backwards to support old dualhead hacks from the mid-1990s. > As has been stated before, we've attempted to continue to support it, > but with the support for more than 2 outputs some configurations (like > yours) break. xrandr 1.2 support has been available for several years > now, and we've only gotten a handful of complains about broken zaphod > configurations. There are just not enough developers to continue > supporting this old stuff forever as well as the new features and > functionality and support for new chips, etc. If the feature is > important to you and your configuration is broken, please consider > sending a patch, this is open source after all. You also still have > access to the old driver if you want to continue to use that. I do know a few people who got an unpleasant surprise when this stopped working for them, only to discover Xorg had taken it out a year or so before but their distro had only just upgraded to that version. They were rather upset and annoyed. (Though conceding the point that Xorg is a few developers desperately trying to drag a huge and mouldering codebase into the twenty-first century, and that the best refutation is patches.) The problem is that stuff gets broken and the people who care about it don't find out until it's way, way too late. This is an example of this bad thing. They're not wrong for wanting their old stuff to keep working, and (rightly, I think) regard it breaking as a regression, one that's quite important to them. (Hence my personal project to build X from source on as many OSes as I can and make it real easy for people to build and run git-master, so they find out about this stuff as early as possible!) Martin - have you tried building an old Xorg from source yourself and using that, rather than the distro version? This would solve your problem and let you use the rest of the modern distro. (Until an app relies on something in a current X ...) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.Org Foundation Board of Directors 2010 Election
On 15 February 2010 20:08, Daniel Stone wrote: > On Mon, Feb 15, 2010 at 01:46:21PM -0600, David Nicol wrote: >> On Mon, Feb 15, 2010 at 1:21 PM, Daniel Stone wrote: >> > (If >> > people want to get paid for hacking X, just mention it and you'll have >> > quite a few companies beating down your door ...) >> You must be exaggerating. > Nope. Fergoshsakes, publicise this more! The impression everyone has is that there's just a few people trying desperately to drag this twenty-year-old codebase into the twenty-first century (let alone the 2010s), and an inexplicable lack of paid jobs working on it ... recruit! recruit! - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SOLVED: modular build, libGL "make install" fails
On 3 February 2010 01:25, David Gerard wrote: > If I shell out and then do ./autogen.sh --prefix=$HOME/mesa then it > works properly. Phew! Wrong directory! That should of course be: ./autogen.sh --prefix=$HOME/xorg-build and possibly a "make" after that. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
SOLVED: modular build, libGL "make install" fails
On 30 January 2010 23:17, David Gerard wrote: > Is this a bug, or just me? This is doing the modular build with jhbuild: > /home/fun/.local/bin/install-check -d /usr/local/include/GL > install: cannot change permissions of `/usr/local/include/GL': No such > file or directory > I'm doing a build in my home directory, but it appears to be trying to > do things to the system. Surely that's not right ... It's just me. Due to http://bugs.freedesktop.org/show_bug.cgi?id=26337 , building with jhbuild requires one to shell out to run ./autogen.sh because jhbuild tries to go straight to 'make'. Doing just ./autogen.sh uses the default prefix, which is of course /usr/local . If I shell out and then do ./autogen.sh --prefix=$HOME/mesa then it works properly. Phew! - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Last call for crusty old non-building drivers impact and sunbw2
http://bugs.freedesktop.org/show_bug.cgi?id=26342 - impact doesn't build in current Xorg. Is anyone still running an SGI MIPS box with an Impact card, who would like to fix the driver? http://bugs.freedesktop.org/show_bug.cgi?id=26343 - sunbw2 is probably dead. But if there's someone out there with a monochrome Sun who wants to run Xorg ... - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular build, libGL "make install" fails
On 31 January 2010 16:31, Dan Nicholson wrote: > On Sat, Jan 30, 2010 at 3:17 PM, David Gerard wrote: >> Is this a bug, or just me? This is doing the modular build with jhbuild: >> /home/fun/.local/bin/install-check -d /usr/local/include/GL >> install: cannot change permissions of `/usr/local/include/GL': No such >> file or directory >> I'm doing a build in my home directory, but it appears to be trying to >> do things to the system. Surely that's not right ... > Mesa is trying to install in /usr/local, apparently. I don't know what > jhbuild is doing, but obviously we'd need to see more context. Indeed. I tried again from clean (and using the jhbuildrc that's actually in git!), but it did it again. I also tried on FreeBSD 8.0 and it *didn't* do this. This sugggests there's some weird config stuff going on here - it does appear to be a build system thing, not a Mesa thing ... will investigate further. (My goal is to make it easy for people to just build Xorg from git head casually and anywhere. This way they won't have to wait until their distro updates to discover that Xorg removed some little thing they happen to rely on a year ago. Also, more eyes = more bug reports, etc.) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular build, libGL "make install" fails
On 31 January 2010 02:44, Jeremy Huddleston wrote: > 1) mesa has its own list Mm. I thought it was relevant to here since it's a mandatory part of building Xorg at all. > 2) you want to use sudo for make install. You need root permissions Ah, but I don't, you see. I'm trying to build this thing (Xorg in all its glory) in my home directory. (Using jhbuild to pull all modules from git and build them module by module.) So why is whatever configuration Xorg is giving Mesa telling Mesa to try to install in the system? That bit's Xorg, not Mesa - Mesa is a third-party inclusion, but it's Xorg giving it build parameters. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
modular build, libGL "make install" fails
Is this a bug, or just me? This is doing the modular build with jhbuild: /home/fun/.local/bin/install-check -d /usr/local/include/GL install: cannot change permissions of `/usr/local/include/GL': No such file or directory make[3]: *** [install-headers] Error 1 make[3]: Leaving directory `/home/fun/git/mesa/src/mesa' make[2]: *** [install] Error 1 make[2]: Leaving directory `/home/fun/git/mesa/src/mesa' make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/fun/git/mesa/src' make: *** [install] Error 1 *** Error during phase install of libGL: ## Error running make install *** [66/168] I'm doing a build in my home directory, but it appears to be trying to do things to the system. Surely that's not right ... What's an appropriate workaround here? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Building X from scratch, jhbuild method - wiki page
Having too much time on my hands, I'm trying building X from scratch, per: http://xorg.freedesktop.org/wiki/JhBuildInstructions I've added to the instructions for how to do it on Ubuntu 9.10. (jhbuild required about 300MB of faff.) Obviously the world isn't Ubuntu or even Linux, so notes for other distros and OSes would be appropriate. (Last time I compiled X from scratch it was FreeBSD in 2003 and took three days ...) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pocket pc as X screen?
2010/1/27 Dave Bender : > Thanks, this is exactly the software necessary for the Desktop Xorg > side; However I still cannot find a pocket pc xorg server though. > (Xming comes up on google, but it uses Pocket PC in the sense of > residing on a USB thumb drive..., not for Windows Mobile) VNC Viewer exists for Pocket PC - if you have an existing X server you can run x11vnc or similar on, you can then use VNC to access it. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: horrible spam
2009/11/29 Barton C Massey : > Options I can think of offhand include > * moderating all postings, for which we would need a > dedicated team of volunteers > * moderating subscriptions, which seems hard > * more sophisticated captchas, perhaps x related, but I > doubt this would solve the problem > Discussion welcome, but it beats me what we can feasibly do > to avoid a repeat. Putting new posters default on moderation and unmoderating when their first post proves human may be workable ... can get slightly laborious for the mods. (I listmod a list with a serious troll problem and this approach works reasonably well for us. It is a damn nuisance though.) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nightly builds?
2009/11/6 Tormod Volden : > On Fri, Nov 6, 2009 at 2:27 AM, David Gerard wrote: >> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported >> architectures (linux/i386, opensolaris, whatever someone will be able >> to commit to build nightly). Download and run. Report bugs. > For Ubuntu there is the xorg-edgers PPA (personal package archive) > which have done exactly this for years: > https://launchpad.net/~xorg-edgers That's perfect :-D (At least for those of us using Ubuntu ;-) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Nightly builds?
2009/11/6 Rémi Cardona : > Le 06/11/2009 08:48, Tormod Volden a écrit : >>> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported >>> architectures (linux/i386, opensolaris, whatever someone will be able >>> to commit to build nightly). Download and run. Report bugs. > Xorg is not your standard application. In nearly all distros, X is > configured differently, with different paths, etc. So even if we did do > binary builds, it would be much harder for users to actually "download > and run". > And now that X drivers are being trimmed down in favor of kernel > drivers, that only makes things more complex. Indeed, there is that. Hmm. >>> 2. Make the source build easier, so people will build and run it from >>> source for the more obscure platforms. > My answer to that would be build.sh or jhbuild. All the info is written > down in the wiki [1]. > Sure it could probably be easier, but it's not like there's nothing at > all. But building from source _is_ tricky and you have to have some > prior knowledge before building large source trees like Xorg. Yeah. But if I can build gcc or KDE with a few shell commands (more than configure && make && make install, but it's still pretty easy), the problem of making it easier is not infeasible. (Of course, then there's the problem of reliable cross-compilation, so you can build it quickly on a modern machine for your old crusty one ... but that'll come next.) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Nightly builds?
I've noticed a few old video chipsets are dropping off the edge of Xorg. This is entirely understandable - Xorg has too few developers desperately trying to drag the 1990s code base into the twenty-first century and there are very few testers for the ancient chips. So many of them have broken, and no-one much notices until the distros release that version of X. No-one wants this to happen, but it does. e.g. Ubuntu 9.10 is fantastic on current chips. (Typing this on my new work Portege R600. Wobbly windows a go go!) But old stuff is showing breakage, and it's unlikely to be fixed. The one thing that occurs to me is: make testing of git head much easier. Much, much easier. 1. Nightly builds. Did wonders for Mozilla. Binary of main supported architectures (linux/i386, opensolaris, whatever someone will be able to commit to build nightly). Download and run. Report bugs. 2. Make the source build easier, so people will build and run it from source for the more obscure platforms. 1. requires build server, web server and bandwidth resources. 2. requires polishing and debugging and making it very easy for people to just keep up with X with a git pull. Ideas? Is this pointing toward something useful? (I'm not a coder myself or I'd be bashing on 2., but I do like reviving crusty old machinery.) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: More old hardware weirdness....
2009/10/27 Yan Seiner : > Now that I have X running, but I can't get the keyboard to work in X. > If I configure things the way I always do,I get nothing. (see below for > xorg.conf snippet.) Does it work with an external keyboard? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: C&T ct65545 problem
2009/10/27 Yan Seiner : > This particular laptop is ISA with a couple of PCMCIA 1 (16 bit) slots. > The video is on the ISA bus. > The chips driver (1.2.1 and 1.2.2) doesn't work in this configuration at > all, exiting with the error given previously. > However, the VESA driver works just fine. It assumes a 24 bit depth and > fails as the hardware only supports 8 bits. Once it's told to use > defaultdepth of 8, it correctly sees the C&T chipset and initializes the > screen just fine. Can this sort of thing be detected and special-cased? (Should it? Would this be an appropriate method of supporting ye crusty olde chips?) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: C&T ct65545 problem
2009/10/25 Felix Miata : > On 2009/10/25 11:40 (GMT-0700) Yan Seiner composed: >> I have a very, very old laptop - 1995 vintage - that I want to repurpose >> for a net-terminal. It has a Chips and Technologies 65545 video >> chipset. This works with X as I've run it in the past with both freeBSD >> and an older version of linux (something with a 2.4 kernel and an old >> version of xfree.) I decided to upgrade this to a current version to >> get some net tools. Now I can't get X to recognize the C&T chipset. > ISTR reading not so long ago about active Xorg devs running out of working > 65545 hardware to test with, and it may be necessary to stick with an older > distro and Xorg version to get it to work, or equip some devs with hardware > matching yours if you can't do the necessary driver dev work yourself. Try > looking through the list's archive if no one else replies with better info. Does anyone know what the last working version was? One of the joys of git is git bisect - it lets you zero in relatively quickly (binary search) on the precise commit that caused a regression. Might be worth trying here. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: problem getting pseudocolor
2009/9/2 Michel Dänzer : > On Wed, 2009-09-02 at 09:41 +0100, David Gerard wrote: >> 2009/9/2 Jerome Glisse : >> > We don't test/use pseudocolor much, i don't even know if it's supposed >> > to work. Why do you want pseudocolor ? You should really stick with >> > RGB32bits visual. >> I would guess: shitty, shitty vertical-market proprietary software >> that thinks it's 1990 and DEMANDS 8-bit colour, and won't run in >> 24-bit colour. I've encountered this stuff. Awful, awful. And >> occasionally necessary. > Those who need that should consider working on > http://bugs.freedesktop.org/show_bug.cgi?id=4770 Yeah, it's part of that "20 years' backward compatibility with horrible stuff" problem, and dragging X11 kicking and screaming into the twenty-first century :-) Usually the vertical market software companies in question deal with it by certifying on a very narrow range of OSes, rather than e.g. filing or fixing bugs. Somewhat less than ideal. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: problem getting pseudocolor
2009/9/2 Jerome Glisse : > We don't test/use pseudocolor much, i don't even know if it's supposed > to work. Why do you want pseudocolor ? You should really stick with > RGB32bits visual. I would guess: shitty, shitty vertical-market proprietary software that thinks it's 1990 and DEMANDS 8-bit colour, and won't run in 24-bit colour. I've encountered this stuff. Awful, awful. And occasionally necessary. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
2009/7/30 Juliusz Chroboczek : > In the departments I know, however, this model is slowly dying out. Now > that fairly powerful fan-less PCs are available at a reasonable price, > we've been migrating to netbooted, disk-less workstations (root mounted > over NFS). This makes it possible to use things like Eclipse, which > would overwhelm the centralised servers. Oh yes. 12W fanless tiny PCs! They make ridiculously overpowered X terminals ... I use one as the household file server and bedroom video player. I can just imagine what someone who did X terminals in the early '90s would make of something that powerful just doing X. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
2009/7/27 Jim Gettys : > walt wrote: >> Being strictly an amateur programmer, I've always wondered how many >> people/institutions actually use X for remote display the way it was >> designed to be used. Seems to introduce a great deal of confusing >> complexity for features many of us never use. > Actually, quite a lot. E.g. HP and others sell thin clients in > commercial (and engineering) settings. And LTSP is quite popular in the > developing world for more general desktop use. Extrapolating yourself > to the world is fraught with difficulties... And things like support for multiple video cards suddenly going away, because the devs weren't thinking outside the case of a Linux workstation with one screen. What other functionality in X isn't used in the "single screen Linux workstation" case and could do with conscious awareness so it isn't inadvertently broken? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: is it possible to publish Xming on Citrix?
2009/7/3 Daniel Stone : > On Wed, Jul 01, 2009 at 11:08:59PM +0530, Venkateswara_Chalamalasetti wrote: >> Recently i have started using Xming free software to connect to one Solaris >> machine. It works. But i have a question in my mind. Is it possible to >> install Xming on WTS and publish Xming on Citrix web page? So that multiple >> users can start using it from one single installation. > We don't really have any control over the Citrix website; you might ask > them. This would be referring to the web page that users launch their Citrix apps from. It sounds like it should be possible - you can make any app available through Citrix, as far as I know. In my last job we had all manner of internal custom software available over Citrix. Of course, it's somewhat painful using one remote terminal (Xming on Citrix) to access another remote terminal (Solaris clients on Xming). But Citrix is very good indeed over low-speed high-latency links - I've seen it usable over a modem link. And I've done so using Citrix (over VPN over DSL) to access Windows Terminal Services (over 100Mbit LAN) to access a Java-based KVM (over 100Mbit LAN) - yes, that's three layers, not two - usably enough for work purposes and only a slight throbbing pain in my forehead. Venkateswara - I'd say you should try it, it'll probably work to some extent, then you can see how practical it is! - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
starter tips on fixing autodtection for a crusty old driver
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/315329 Ye olde ancient Trident driver doesn't autodetect 1024x768 properly - it sets the display to 800x600 as the biggest supported mode. Looking at the xorg.0.log, it detects the TFT as 1024x768 properly, but thinks all 1024x768 modes are out of hsync or vsync range. Now, (a) it would be nice to have this autodetect because xorg.conf sucks (b) it's a crusty old driver which even I would class as "we welcome your patch" rather than any sort of showstopper. So. Where would one start on fixing autodetection code for a crusty old driver? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Skype causes a segmentation fault (1.6.2 RC1) and restarting of the X Server
2009/6/18 Miro Hadzhiev : > Am I at the right place? No reply so far. Do I need to file this particular > bug concerning Skype and the segmentation fault of X Server somewhere else? > :) Well, clients shouldn't be able to make the server segfault, so it's a bug. The hard part is debugging it, as Skype's a closed source application ... to file a bug that others could make sense of, you'd need to get some idea of what was happening. Run a debug version of latest Xorg, trace precisely what's happening, see if you can spot what Skype is mis-tickling ... - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: help configuring a 30" apple cinema display
2009/6/4 Robby Findler : > That did it!! So how many others reading this thread were just envious of his two huge really really nice displays? :-) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching between virtual desktops
2009/6/2 Luca Bezerra : >> 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
2009/6/2 McDonald, Michael-p7438c : > Where are the monitors coming from? If you're buying them, then there is > money to buy cheap, modern PCs to run each station. If the monitors are > surplus, then check with you university's surplus property department about > getting ahold of discarded computers. 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. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Window structure digram
2009/5/31 ZHOU Guibin : > I am investigating and building the X Window System manually these > days, I draw a X Window structure digram, including the dependency(hope it's > right) . You can find it in the attachment if you are interested. > My understanding in the X Window might be not totally true, so any > suggestions is welcomed. And I really want to learn more. If a corrected version of this can be released under a suitable license (e.g. the X11 licence), it'd be an excellent addition to the [[X.Org Server]] article in Wikipedia, and possibly [[X Window System protocols and architecture]]. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Only use part of display..?
2009/4/24 Yan Seiner : > On Fri, April 24, 2009 3:39 pm, Danny Ayers wrote: >> Slightly odd request - the display on my EeePC got damaged (left it in >> the car in winter - literally frozen I believe) so now the pixels in >> the top RH corner are screwed (lovely snowflake pattern). >> So I was wondering if I could tell X to use only the LH 7/8 of the >> display. This is the most outlandish tech support problem of the day. > Run Xephyr on top of a blank X server? And it actually got an answer! Here's to open source :-D - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bug# 1382
2009/3/17 Alan Coopersmith : > Dennis Quelch wrote: >> I've stumbled across bug 1382 in my software dealing with the out of date >> motif header files that are used to construct the xorg-x11-6.8.2-1.EL.18 & >> 52 rpm's. These out of date headers are causing seg faults when attempting >> to use glwMDrawingAreaWidgetClass due to the size differences between the >> GL's PrimitiveP.h file and the one included with Motif2.2. I've noticed >> this still has not been resolved. Will a fix be added for a future release? > Xorg 6.8.2 is a very out of date release, and is years behind what we're > currently distributing (X11R7.4 is the most current release of the X Window > System). As noted in that bug report, we can't find the files referenced in > anything X.Org or Mesa is currently distributing, so it sounds like you need > to ask your xorg-x11-* RPM provider when they will update to a newer release. > (X.Org only releases the source files - RPM's and other package formats are > put together by others.) Those look like Red Hat Enterprise - RHEL4 era, I think. Definitely one for paid distro support. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
(trivia) XCB kitten logo?
A completely trivial question: what's the origin of the XCB logo, the kitten with the big feet? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
2008/12/10 Charles Lindsey <[EMAIL PROTECTED]>: > HOWEVER, a compactor within the Xserver should, in principle, be possible, > because large Pixmaps and the like are referenced by a serial number > rather than by their address in (virtual) memory, and hence it should be > possible to relocate them and simply alter the table that accesses them. > That might need to be done in conjunction with a specially-written malloc > for internal use within the Xserver, but specially-written mallocs are > already in use in lots of other contexts. Firefox went as far as adopting and adapting jemalloc to do this job inside their own application given to large memory sizes, fragmentation and leaks. So it's hardly unprecedented in an app that does a lot of malloc churning. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
2008/12/9 Adam Jackson <[EMAIL PROTECTED]>: > 1) vm86 mode is an x86ism. It doesn't work in long mode, and almost > certainly never will. 64-bit desktops are an increasingly large > percentage of the world. It's worth having only one set of bugs, for > the same reason we don't ship cfb anymore. Quick off-topic historical question - what is/was cfb? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft: License policy for contributors
2008/12/3 Adam Jackson <[EMAIL PROTECTED]>: > http://www.freebsd.org/copyright/freebsd-doc-license.html > It's more explicit than I think is directly appropriate for X, since > much of our documentation source is not DocBook. But. OK (probably). Any other licenses in the X.org tree that are worth considering the qualities of in this regard? (Much as you probably have considered the thousand and one BSD/MIT-like code licenses that companies insist on handrolling.) > There's a tension here in that you'd like invariant sections so you can > say things like "the authoritative version of this doc is here" and > point back at the x.org versions, but that runs you right into > DFSG-non-free land. I guess the question is what we'd lose by going > with an MIT policy (asserted copyright + liability waiver + free > modification). I mean, if someone published a buggy version of the > protocol spec in a book, it's certainly much easier to address that > through publishing _more_ information (like errata on a web page) than > by legal injunction. And it's not like there is serious competition out > there for the definition of the protocol. X is mostly licensed under the MIT licence, which is about as open as you can get without being public domain. X.org holds itself together not by copyleft code, but by having a project that's worth participating in the main tree of. So yeah, "use our stuff - please!" is similarly appropriate for documentation. Humble suggestion from someone who hasn't looked into it: Compile two lists, one of all code licenses in the tree, one of all doc licenses in the tree. Evaluate for free-as-in-take-our-stuff-please qualities. Discuss on list. > The more I read CC-BY 3.0, the less I like it. Section 4c seems to > imply that, if we released the protocol doc under CC-BY, you'd be > prohibited from including it in a book entitled "World's Greatest > Software Engineering Disasters", which I'm pretty sure counts as > non-DFSG (and also flatly inappropriate, since oh boy are we ever > engaged in pig-lipsticking here). heh :-) It's intended for creative works, not documentation really. You could add a provision "by the way, in our use these clauses don't apply," which would be upwardly-compatible with CC-by. Disclaimer: I am not a lawyer or particularly expert in these matters, except having been deep in the wrangles over deep copyright nerding on the Wikimedia/Wikipedia lists, particularly the Wikimedia Commons list - which is where we try to work out what licenses and conditions allow stuff to be free content over as much of the world as possible. So I might be what counts as an expert in many of these contexts ;-) You would probably believe how complicated this can get. (The Wikimedia Foundation definition of "free content" is as defined at http://freedomdefined.org/ , which just happens to have been written by one of the WMF board members, now WMF staff. So that's useful.) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft: License policy for contributors
2008/12/2 Adam Jackson <[EMAIL PROTECTED]>: > On Wed, 2008-12-03 at 06:28 +1100, Daniel Stone wrote: >> On Tue, Dec 02, 2008 at 01:48:31PM -0500, Adam Jackson wrote: >> > I don't know what our documentation licensing stance is. MIT would keep >> > things simple, but I don't know if it's appropriate for docs. >> What're our options? GFDL is out as DFSG-incompatible. > Yeah, MIT does seem to be a good plan, at least for the non-spec > documentation. Alan and Mikhail do mention CC-BY, which might be okay > for spec docs? Would have to check. CC-by is a permissive licence for text. To what extent is it compatible with MIT, in which directions? c.f. the case of mixing MIT, BSD (in its many variations), similar permissive licenses ... How well understood are the implications of MIT as a licence for text? (c.f. GFDL, which makes less sense the closer you look at it.) This level of consideration is worthwhile as licences are a hideous nightmare and getting it right now is vastly superior to getting it not quite right now and needing to fix it later. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft: License policy for contributors
2008/12/2 Daniel Stone <[EMAIL PROTECTED]>: > On Tue, Dec 02, 2008 at 01:48:31PM -0500, Adam Jackson wrote: >> I don't know what our documentation licensing stance is. MIT would keep >> things simple, but I don't know if it's appropriate for docs. > What're our options? GFDL is out as DFSG-incompatible. GFDL is an unspeakable Cthulhu-grade horror if you go anywhere deeper than the surface. It's amazing how little types of stuff it actually makes sense from; no-one knows what the hell would happen in a serious courtroom stoush given the already vast disparity between the letter of the license and widespread practice. Learn from Wikipedia's HORRIBLE, HORRIBLE MISTAKE. Don't go there. Whatever you do. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Accelerating Ogg Theora and Dirac (was: MPEG-LA / Todo list)
2008/11/24 Stan Cunningham <[EMAIL PROTECTED]>: > As for the last part about the decoder, it would be nice if all FOSS drivers > (OpenChrome, Radeon, Intel, etc) could share the same Theora and Dirac > decoder. The libs are BSD-licensed, and are present on most free Unix-likes and have no legal encumbrances for distribution with others. Firefox 3.1 will include Theora - perhaps for FF4/Gecko 2, something could be worked out for the browser to use the OS/Xorg installation where available. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LBX? or faster remote X?
2008/11/4 Alan Coopersmith <[EMAIL PROTECTED]>: > Jeremy C. Reed wrote: >> I don't see lbxproxy listed in the X.org 7.4 release. But it is in 7.3. >> What is its status? > Deprecated. I did start this: http://en.wikipedia.org/wiki/Low_Bandwidth_X Jim Gettys has edited it, anyone else who wants to tweak it is most welcome to. (Wikipedia's X coverage is far from perfect, but I'm quite pleased with how much it does cover.) - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to implement alternate zap key idea
2008/9/24 Igor Mozolevsky <[EMAIL PROTECTED]>: > 2008/9/24 David Gerard <[EMAIL PROTECTED]>: >> FWIW, I tend to kill X not with ctrl-alt-bs but by going to a non-X >> console with ctrl-alt-F2 and sudo pkill Xorg. I suppose that's a bit >> Linux/FreeBSD-specific, of course. sshing in from another machine also >> works well. > BTW, you can also kill it by switching to the terminal you ran it from > (ctrl+alt+f1 usually) and just ^C-ing the running process... Obv. this > requires you to have started X manually... I use Kubuntu 8.04 with KDE 4.1, which goes straight to a graphical kdm login. KDE 4.1 is still not entirely polished and occasionally forgets where its backside is, so has to be hit over the head. I'd like to do something less drastic than kill X, but haven't found what yet. (I should really get around to hitting the Ubuntu forums.) Note that this is a case of a user having a frequent need to kill X reliably. Sometimes ctrl-alt-bs just doesn't work (evidently it forgets or no longer cares that it's got a keyboard). I also really need to get around to some serious Kubuntu/KDE bug-reporting ... - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to implement alternate zap key idea
2008/9/23 Jaymz Julian <[EMAIL PROTECTED]>: > Lots of things "shouldn't" happen, with computers. One day, we will > make them bug free. And no-one will ever have to kill X again, or it > won't be the easiest way out at least. Or maybe reboots will be > fast enough to not bother for users. At which point you can > ctrl-alt-del again, but then we'd be having the same discussion > anyhow... FWIW, I tend to kill X not with ctrl-alt-bs but by going to a non-X console with ctrl-alt-F2 and sudo pkill Xorg. I suppose that's a bit Linux/FreeBSD-specific, of course. sshing in from another machine also works well. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
OpenGL is free free free software
http://www.linux.com/feature/148339 SGI used their "or later" privilege to upgrade to the X11 licence. w00t! - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
