Re: unable open xterm
Usuário do Sistema maico...@ig.com.br writes: yes! I'm trying open a window xterm from ssh connection. how I'm doing: from my windows machine ( with Win 7 ) I conneted to my X Server machine by Puty. there I run the xterm command. the X server Machine hasn't a monitor! the daemon xfs it's up but the problem still occur: -bash-3.2# echo $DISPLAY :0.0 -bash-3.2# xterm Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm Xt error: Can't open display: %s If you want to see the xterm window on your windows machine, you'll need: 1. Run an X server on your windows machine. 2. Configure PuTTY to use X11 forwarding. 3. Ensure ssh on the linux machine allows X forwarding. 1. There seems to be several X servers that can run on windows, e.g. XMing (http://www.straightrunning.com/XmingNotes/) or XWin32 (http://www.starnet.com/products/xwin32/). I haven't tried any of them, as I don't run windows myself. On the other hand, if this used to work for you (and you haven't reinstalled windows or otherwise uninstalled the X server on your windows machine), you should already have it. 2. The first hit on google says that PuTTY has a setting Connections-SSH-Tunnels-X11 forwarding. You'll need to make sure this one is turned on. 3. On the linux machine, you may need to do something to /etc/sshd/sshd_config. You probably need to make sure a line like this is in sshd_config: X11Forwarding Yes If you've got all that right, you should not need to set DISPLAY on the linux machine. It should be set automatically by ssh. If your sshd_config does not specify otherwise, you will most likely have a DISPLAY value of :10.0 (NOT :0.0). See man sshd_config (on the linux machine) for details (X11DisplayOffset, in particular). eirik ___ 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: unable open xterm
Usuário do Sistema maico...@ig.com.br writes: Thank you Thomas. but it wasn't work. 1- bash-3.2# xterm -display :0.0( here I was logged by SSH using Puty from my windows machine ) Warning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted in this environment. You may get a more descriptive message by running the program as a non-root user or by removing the suid bit on the executable. xterm Xt error: Can't open display: %s 2- bash-3.2# xhost +localhost xhost: unable to open display :0.0 Are you sure that there is a running X server on that computer? It seems to me that you are trying to make the window appear on the X server without a monitor. Is that really true? I would have thought that it would be more useful to have the xterm window appear on the monitor that you can actually see. Em 9 de maio de 2011 18:07, Thomas Dickey dic...@his.com escreveu: If you're logged in as root, then the X libraries (from ~10 years ago) will ignore the $DISPLAY variable. It used to be a reliable workaround to simply use the -display option (but I've seen a few machines where that's been broken). That is xterm -display :0.0 As noted, if you were using ssh -X, then the display would be set more/less automatically. Except that it seems he is trying make the xterm window appear on the X server that does not have a monitor connected. ssh -X would try to make the xterm window open on the monitor which he is looking at. eirik ___ 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: A question about fonts
Andersen, Jan jander...@informatica.com writes: So your problem is that the web browser you are using fails to display all the glyphs? That sounds like an issue with that application. I would think all main web browsers today would have proper font switching support. That is, if the font they are using does not support a specific glyph, they will use a different font for that glyph. A possible complication could be if there is a font on the system that claims to support the glyph but renders it as a glyph-not-found shape. (I think I have seen that happen.) It would probably make sense to take the question to the web browser's forums. (That isn't to say that X and related technologies (e.g. fontconfig) can't be improved to make it easier for applications to do proper font switching, of course.) eirik ___ Thanks for helping, Eirik. I'm not really sure the problem is the browser as such - the characters that are missing in the browser are also missing in the font when I look at them with Fontforge, and then there is the problem with a large number of them being outside the range of any single font. I suppose this is something you wouldn't really come across much unless you try to do something like what I am doing, where you systematically go through everything. Missing characters I simply fill in when I have time, so the only remaining problem is the sheer size of the set of characters. It doesn't matter that no single font handles all the characters. The web browser should detect that the font it is using can not handle some glyphs and use a different font for those glyphs. I know that Opera does this (since I've actually worked on that code). If you have fonts that together support all your glyphs, and opera fails to display some of them, then that is (probably) a bug in Opera. This is particularly important for applications like web browsers which are likely to be asked to display a wide variety of writing systems. There are quite a few people in the world who reads multiple languages using multiple writing systems. So, I will go away and study fontconfig now. Thanks to everybody for being so patient with me. I don't think fontconfig will solve the problem on its own. I think the application will actually have to do the job of switching between fonts, but fontconfig can provide some information to help the application do a better job. eirik ___ 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: A question about fonts
Nicolas Mailhot nicolas.mail...@laposte.net writes: I don't think fontconfig will solve the problem on its own. I think the application will actually have to do the job of switching between fonts, but fontconfig can provide some information to help the application do a better job. fonctonfig provides the info for higher level libs (pango, harfbuzz) to do the switching. An app should never implement a switching logic directly (that confuses users when different app make different switching decisions instead of relying on system libraries) That's a nice theory, but not very useful for applications that had their text layout and rendering engines written before pango/harfbuzz became universally available system libraries. Seriously though, I think this is a good plan. Doing font switching, glyph shaping etc. correctly is a major pain and tends to involve user configuration anyway. Getting all of that done by a system library would be great. But there are some obstacles. First of all, the API of such a system library must provide the functionality needed by the applications in such a way that the applications can effectively make use of it. Maybe pango/harfbuzz does that. I don't know, I haven't had the time to look into it yet. And even if that is true, I expect rewriting applications to make use of this API is a non-trivial amount of work. And if the application will also support systems that may not have pango/harfbuzz available, the application will still have to carry its own implementation around as well. But yes, I seriously look forward to the day we start using a system library for this. eirik ___ 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: A question about fonts
Andersen, Jan jander...@informatica.com writes: Sorry for posting this here, where it is almost certainly not appropriate, but I don't quite know where to ask, and I suspect some of you guys probably do. So, this is my question: I work a lot with Chinese, and need to be able to display the full range of CJK characters in Unicode; unfortunately that exceeds the capacity of all current font specifications (that I know), and I would like to see if I can do something about it. After all, when you display a character, what you need is to take your character representation (eg UTF-8) and look up a glyph - if things are reasonably sensible, it ought to be fairly doable to replace that part from somewhere and replace it with, say, a database interface. But where do I even begin to understand font-handling in X? The really short answer: X doesn't do fonts. Current thinking is that glyphs should be rendered by the client application into images, which are then passed on to X and rendered using plain image composition rather than a text-specific api. X does have a font api. It even has an api for using multiple fonts at once to render text that require several fonts, see XCreateFontSet(). But the font api has some weaknesses that easily becomes significant for modern applications. It is not entirely obvious what you want to accomplish. Are you writing an application that displays text? Then any sane modern toolkit should handle the problem for you. Of course, proper text rendering is a bit more complex than taking each unicode code point and render that as a glyph. Some writing systems and some typographic conventions renders some unicode code points differently depending on the surrounding glyphs. In european typography, the classic example would be the 'fi' ligature. Also, a single character may be represented as more than one unicode code point, in particular when using combining characters. I guess this is largely a non-issue with Chinese. And while unicode does provide combining characters for Japanese, you can probably eliminate them without loss of information by a preprocessing step (i.e. I believe there exists unicode code points for the composed form of every interesting glyph for Japanese). Not to mention that a unicode code point does not encode a glyph, not even when the code point is a fully composed character. A unicode code point encodes a character. And the same character may have different glyph representations depending on language. (It is a bit unclear to me how important this is in practice, though.) eirik ___ 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: A question about fonts
Andersen, Jan jander...@informatica.com writes: It is not entirely obvious what you want to accomplish. Are you writing an application that displays text? Then any sane modern toolkit should handle the problem for you. = Hi Eirik, No, no, nothing as ambitious as that. I have a problem when I study Chinese: there are many good dictionaries, but the electronic ones invariably assume that you have the text in electronic form, and the paper one are big and bulky. The texts I read are printed on paper, and I find the best index method is the radical based one; but it makes the lookup cumbersome for obvious reasons. So, I have gone to the Unicode Consortium, downloaded their CJK related data, formatted it somewhat, loaded it into a MySQL database, extracted a huge-ish set of static web-pages that I can now use to look up characters using a radical index on a computer; I can then use an electronic dictionary to give me the last step. It is actually quite handy, if not excessively elegant, but some characters come up as blank squares. There is a pair of fonts (called han-nom for some reason) that seems to cover a large part of the interesting range, and I wasn't aware that Fontconfig can help me there, alleged ly. So I am going to learn about Fontconfig now. So your problem is that the web browser you are using fails to display all the glyphs? That sounds like an issue with that application. I would think all main web browsers today would have proper font switching support. That is, if the font they are using does not support a specific glyph, they will use a different font for that glyph. A possible complication could be if there is a font on the system that claims to support the glyph but renders it as a glyph-not-found shape. (I think I have seen that happen.) It would probably make sense to take the question to the web browser's forums. (That isn't to say that X and related technologies (e.g. fontconfig) can't be improved to make it easier for applications to do proper font switching, of course.) eirik ___ 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: ssh -Y -l user etc,etc
gene heskett ghesk...@wdtv.com writes: On Thursday, February 24, 2011 10:23:08 pm Glynn Clements did opine: gene heskett wrote: So that probably explains where the 10.0 is coming from, but not where I might change it? That seems to be the $64k question... Why do you need to change it? Because its not working? :) I think we're getting to the root of the problem here :) So, you want to run emc on the machine called 'shop', and you want it to display its UI on the machine called 'coyote'. Using 'ssh -Y shop' (on coyote) will make ssh create a proxy X server on 'localhost:10.0' on 'shop' (by default). This X server will only forward all requests to the real X server on 'coyote'. That's why you would want the DISPLAY variable to say 'localhost:10.0'. In principle, you could set DISPLAY to 'shop:10.0' and connect to the same X server (the proxy created by ssh), but that requires setting X11UseLocalhost to no. And it probably won't help, unless emc is doing something very strange when it tries to connect to X. To connect directly to the real X server, you'd have to set DISPLAY to 'coyote:0.0' (assuming the X server on coyote is using the default setting). However, that will only work if: 1. The X server on coyote is set up to listen to tcp. 2. You have set up the proper credentials to allow connections to it. For 1, most current systems turn off tcp support when starting X as it is not particularly useful (for most people) and an obvious security issue. I assume this is still done by passing the '-nolisten' option on startup of the X server. For 2, you have to wrestle with xauth or xhost to get things set up correctly. However, I suspect this isn't really what you want anyway. None of this should be necessary. 'ssh -Y' should be plenty of good enough. It is probably best to split up debugging into two stages: first make sure the X setup works, and then figure out why emc fails to use it. If a simple X application (e.g. xterm) can successfully start up on 'shop' and display its window on 'coyote', then the X setup is working and you shouldn't need to fiddle with DISPLAY or X11UseLocalhost. If xterm works correctly, then it is most likely emc that has a bug of some sort. It could be useful to try setting X11UseLocalhost to no, just to check that it doesn't make a difference. (If that actually makes emc work, it is probably about time to make a bug report to emc...) [...] X11UseLocalHost is #X11UseLocalhost yes in /etc/ssh/sshd_config commented out. Does changing that need a reboot? You'd probably need to restart the ssh daemon, but that should be sufficient. Though I don't think changing this setting will help. gene heskett ghesk...@wdtv.com writes: On Thursday, February 24, 2011 12:41:00 pm Eirik Byrkjeflot Anonsen did opine: gene heskett ghesk...@wdtv.com writes: [...] Now, the fix that did make it work before is still there: gene@shop:~/emc2/configs/genes-mill$ echo $DISPLAY localhost:10.0 I assume you haven't set that yourself, but that it gets automatically set by ssh? No, but I forget where I put it, so a grep -R 'DISPLAY=localhost:10.0' / is pounding the 'shop' machines drive looking for it now. Then it is probably set by ssh when it starts up. Which is the way it should be. [...] In fact, both machines are running X. Hmm, then it would be interesting to test if emc can run correctly locally on 'shop'. Just to make sure that it is in fact something about the remote X setup that fails. eirik ___ 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: [Bug 34004] New Account Request
Luc Verhaegen l...@skynet.be writes: On Thu, Feb 10, 2011 at 07:56:04AM +0100, Eirik Byrkjeflot Anonsen wrote: Luc Verhaegen l...@skynet.be writes: On Wed, Feb 09, 2011 at 03:02:58PM +, Daniel Stone wrote: On Wed, Feb 09, 2011 at 03:43:07PM +0100, Luc Verhaegen wrote: On Wed, Feb 09, 2011 at 06:36:32AM -0800, bugzilla-dae...@freedesktop.org wrote: --- Comment #4 from Daniel Stone dan...@fooishbar.org 2011-02-09 06:36:31 PST --- done Root access restored, i presume? Yes. Tollef's opinion was that quitting was a copout and that I should instead go fix some sitewranglers bugs instead. Until the next time you're drunk, i'm sure. It sounds like you are saying that Daniel should be banned from further participation in xorg for life. There is a huge difference between participation and being fully reinstated into a position that has been abused before. Then maybe you should have been more careful to word your complaint in a form that clearly said exactly what you were complaining about, as well as what you think should be done about it. Don't leave it to the reader to guess. (If you do choose to make a case, take the time to make sure your arguments are well thought out before posting. Remember, your arguments will have to sound convincing to a large number of people on this list, or you may as well not bother.) All arguments were made, extensively, before. Fine. If you think the arguments are well-known, then there is no need to repeat them. But you still have to clearly state what action you expect someone to take. Otherwise, you will most likely just be ignored. eirik ___ 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: [Bug 34004] New Account Request
Luc Verhaegen l...@skynet.be writes: On Wed, Feb 09, 2011 at 03:02:58PM +, Daniel Stone wrote: On Wed, Feb 09, 2011 at 03:43:07PM +0100, Luc Verhaegen wrote: On Wed, Feb 09, 2011 at 06:36:32AM -0800, bugzilla-dae...@freedesktop.org wrote: --- Comment #4 from Daniel Stone dan...@fooishbar.org 2011-02-09 06:36:31 PST --- done Root access restored, i presume? Yes. Tollef's opinion was that quitting was a copout and that I should instead go fix some sitewranglers bugs instead. Until the next time you're drunk, i'm sure. It sounds like you are saying that Daniel should be banned from further participation in xorg for life. If that is really what you mean, make your case for it. Don't just make snide comments. They aren't helpful. If you were trying to be funny, I fail to see the joke. (If you do choose to make a case, take the time to make sure your arguments are well thought out before posting. Remember, your arguments will have to sound convincing to a large number of people on this list, or you may as well not bother.) eirik ___ 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: Documentation
Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl writes: i am not claiming toolkits are useless, was more adressing statements like you really want (for simple app - not really) and qt and gtk are best choice (quite bold, almost advertisement-like claim. There are applications where you are better off bypassing toolkits and coding towards X directly. Maybe you have no GUI (e.g. devilspie, xwininfo, xdpyinfo). Maybe you want to use weird features of X that interoperates badly with the current version of your chosen toolkit. But as soon as you want proper multilingual text input or output, a file dialog, a standard menu bar, or even want to support cut'n'paste, a proper toolkit can save you a lot of pain. (And don't get me started on colour models, proper window manager integration, optimized rendering, printing, skinning...) Most simple apps want some of that. (Besides, for most simple apps there is even less point in spending a lot of effort on stuff that a toolkit will give you for free...) Yes, there are other toolkits that can be used instead of qt or gtk. I still maintain that those are *probably* the best choices these days, quite simply because I believe those are the big ones and thus *probably* better tested, better documented and better supported. Of course, other toolkits may be better for some kinds of applications, and some programmers will prefer differently designed APIs. eirik ___ 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: Documentation
Nima Sahraneshin unix.n...@gmail.com writes: Hi I want to write a program based on X .I need some documentation about X (using X) . Assuming that you want to make an ordinary application that is going to run under X, you really want to use a toolkit. These days, Qt (http://qt.nokia.com/) and Gtk (http://www.gtk.org/) are probably the best alternatives. They are much easier to work with than coding directly for X, and they do a lot of things for you that is otherwise a royal pain to get right. eirik ___ 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: companies contributing to X
Matt Dew m...@osource.org writes: On Thu, Nov 25, 2010 at 5:36 AM, Eirik Byrkjeflot Anonsen ei...@opera.com wrote: [...] I can see some reasons why companies would not want to contribute and also not want to say why: - They wish X.Org would just go away, because then they think they'll have less competition. Who are the competitors? Besides Xi graphics, do you include FB or wayland here? Not competitors to X.Org, but competitors to their company. If they improve X.Org, they also improve the software stack of their competitors. Also, if they have a good market share, a common software stack (like X.Org) makes it easier for their customers to switch to one of their competitors, as there is a large layer of compatibility in place. - They believe they gain a competitive advantage by keeping their clever code to themselves. - Their code is so shitty that they don't want anyone else to see it. This one I can definitely believe. :) I figure this is pretty typical for a lot of closed code. It is hard to justify putting in the effort to bring code from shippable to maintainable when there are so many other important bugs to fix and features to implement. (I'm sure this applies to open code too, by the way. But I think some of the social mechanisms surrounding open code is less conducive to this kind of thinking.) [...] I would assume that the main stumbling block to contributing to X.Org is quite simply that it takes time and effort to get X.Org to accept a patch. And since the company has already shipped it, they don't see the immediate benefit of spending this effort. I would think this is a serious issue, but I don't think there is any way to eliminate it. I expect it is usually true that some time and effort is needed to bring a patch from it works, ship it to something the X.Org developers should be happy about maintaining. This one seems most likely. If it's the in-house developer(s) who isn't all that interested in giving back and won't go out of his/her way at all, then there's nothing we can do and I don't want to spend effort here. There is the option of attitude adjustment through propaganda. There are benefits to getting your code into X.Org, most importantly a lower maintenance burden. Also, as long as X.Org maintainers must accept code before it enters the X.Org codebase, this also somewhat doubles as a free code review. (Not everybody likes code reviews, but it usually makes the code better...) And even if the code isn't accepted, it could be the push that makes X.Org developers implement the feature themselves. There's nothing like demonstrating a (partial) solution to a problem to get other people to put some work into that same problem :) If it's an in-house developer(s), who would be willing to try to work with Xorg devs to get it in tree, then this is the case I'm interested in. Can we make it easier for him/her without killing ourselves? I see I forgot one other issue: The IP rights management maze of the company needs to be successfully traversed before any contributions can be made. This can be a huge issue, as it involves getting the company to make a legally binding commitment. Apart from making sure the X.Org licenses are generally palatable, I'm not sure what else can be done about this. FSF has some boilerplate legalese that many companies feel reasonably comfortable about signing. Something like that could be an idea. Then again, FSF requires a real signature for transfer of ownership of code before accepting contributions, which does make the problem more pressing. eirik ___ 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: Respository vandalism by r...@...fd.o
Luc Verhaegen l...@skynet.be writes: On Wed, Nov 24, 2010 at 04:36:17PM +1000, Dave Airlie wrote: On Wed, Nov 24, 2010 at 4:31 PM, Luc Verhaegen l...@skynet.be wrote: See, this was exactly the problem here. It _was_ a freedesktop admin. And it was pretty clear that it was that from the onset too. Mailing fd.o admins, even if i could've dug up an email address in the split second that i wrote the email (heck, i even mistyped repository), was not the right course of action. (As an aside: maybe it would be a good idea to spend more than a split second on writing an email of this kind?) So you mailed 2 mailing lists consisting of 2-300 people who could do nothing about it? nice work. Dave. Stop the counter-attack dave, it's far too obvious what you are doing here. His response seems quite reasonable to me, assuming that he thought your intention was to get the problem looked into rather than just raising a stink. On the other hand if your intention was primarily to make a lot of noise, then clearly your action was a reasonable one. Which brings me to: The means to the end were perfectly justifiable under the circumstances, and this includes the years of experience i have with dealing with X.org community. This especially includes the experience of something as noble as the radeonhd driver project. Then what was your intended end? Has it been accomplished? As far as I can see, all you've managed to do is to create a lot of noise about what is, in itself, a fairly minor incident. Yes, it is serious that a trusted admin abuses his powers. However, that happens and will continue to happen. Humans are like that. We often show a remarkable lack of good judgement. And in this case, I think the pattern matches well with bad judgement rather than evil intent. What I'm far more worried about are the admins (and non-admins) who have made changes with evil intent that we have not noticed. I am not particularly worried about this incident, as anyone with true evil intent would not have advertised their actions like this. However, that doesn't mean that no-one have acted with evil intent, and been successful at it. There are two things that I feel are important about this: 1. What systems do we have in place that enables us to detect when a trusted admin acts in bad judgement or with evil intent? What is the probability that such actions will be noticed? Can we do anything to increase this probability? 2. What systems do we have in place that enables us to detect evil commits once they actually make their way into the repository? What is the probability that they will be noticed? Can we do anything to increase this probability? You'll notice that none of these are directly related to this incident. This incident only provides an excuse for bringing up such issues. If that was your goal, then I feel that it has not yet been accomplished, but making noise about it may have been a reasonable approach anyway. More related to this incident (and your comments) could be this issue, which I consider slightly less important than the previous two, but is still a quite significant point: 3. When incidents are detected (break-ins, abuse of admin rights, evil commits, what have you...), what processes are in place to deal with this? What information is published, and in which fora, and when? What investigations are performed, and what actions are carried out as a result of such investigations? Where are these processes documented? Of course, I have my own suspicions about the answers to all three questions, but that's not the point. The point is that the people who actually deal with these things must reflect over whether what we are doing is good enough or whether we should do better. (It goes without saying that we could do better, the question is whether it is worthwhile to spend effort on actually doing better.) I know that all this work is largely carried out by volunteers in their spare time. That doesn't make my three questions unimportant. (I'll just end by pointing out that whenever I say we above, of course I mean you, considering how much I personally have contributed to this project. Thank you for all the good work, it is deeply appreciated.) eirik ___ 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: simple X window program not compile, plz help
eric lin fs...@luxmail.com writes: dear Alan or any x window user/programers: it compile success by your last suggestion but when I run it, Segmentation fault (anyone can tell me why?)(that book's code actually is already illegal on my system's x window grammer, plus I have hard time to figure it out what that book's authors's explanation. But I won't abondon it in short time.) that book is really pretty unorganized, especially code in ununiform. But that is so far I can get most approach to X on linux, which is I borrow from Los Angeles's central city library at downtown. I also see another book, Motif, in that library also doing graphic on Unix, written by c++. I search a little bit on google's motif part, i find a simple c code and I copy it and try to compile it on my system, but it not work --- r...@eric-laptop:/home/eric# gcc try3.c -lXaw -lXt -lX11 -lXm try3.c:2:20: error: Xm/Xm.h: No such file or directory Here's your (first) problem. You need to install the development package for motif as well (probably libmotif-dev). (Also, you should place -lXm before -lXt on the command line, and you can probably drop -lXaw). But really, take Alan's advice and start looking at Qt or Gtk instead. They are much easier to program, and are generally better in every way. eirik ___ 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
Guarantees of order of X events vs requests
What guarantees does X give when it comes to the order of events generated in relation to processing of the requests sent by the client? (Also, of course: To which degree does various implementations of X actually fulfill these guarantees?) Some specific questions: X events have a serial value. I expect that any event delivered by X will reflect the state after the request number serial (and all preceding requests) have been processed. Is this correct? Can I also assume that the X event will reflect the state before any requests with a later serial number is processed? (And I assume that serial is monotonically increasing, except on wrap-arounds...) Context: Given an application that frequently performs a sequence of XCopyArea() calls on the contents of a window. When this application receives Expose events or GraphicsExpose events, it is necessary for the application to know exactly which XCopyArea calls have taken effect to be able to correctly calculate which area of the window has become invalid. eirik ___ 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: Guarantees of order of X events vs requests
Maarten Maathuis madman2...@gmail.com writes: On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen ei...@opera.com wrote: What guarantees does X give when it comes to the order of events generated in relation to processing of the requests sent by the client? (Also, of course: To which degree does various implementations of X actually fulfill these guarantees?) Some specific questions: X events have a serial value. I expect that any event delivered by X will reflect the state after the request number serial (and all preceding requests) have been processed. Is this correct? Can I also assume that the X event will reflect the state before any requests with a later serial number is processed? (And I assume that serial is monotonically increasing, except on wrap-arounds...) I think the ordering is kept for obvious reasons, but you don't know when you'll see the result. X is required to produce the same result as if all requests were handled strictly in-order, but the server can reorder requests as long as the client doesn't notice the difference. I'm not so sure the serial member of events are included in the set of observable effects, and I'm even less sure that implementations have kept that in mind. So can I be sure that an event will reflect the state resulting from exactly the requests with request number serial and earlier having been executed? Context: Given an application that frequently performs a sequence of XCopyArea() calls on the contents of a window. When this application receives Expose events or GraphicsExpose events, it is necessary for the application to know exactly which XCopyArea calls have taken effect to be able to correctly calculate which area of the window has become invalid. I think you are supposed to draw the entire area that is exposed. If that is too costly, maybe render to a backbuffer and copy to the window. Just my two cents. I certainly intend to draw the entire area that is exposed (typically from a back buffer, yes...). The problem is, I don't know where in the window that area is now. The event only tells me which area of the window was exposed at the time when the event was generated. If one of the XCopyArea requests are executed after that, then the invalid area will move too. eirik ___ 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: Guarantees of order of X events vs requests
Soeren Sandmann sandm...@daimi.au.dk writes: Eirik Byrkjeflot Anonsen ei...@opera.com writes: What guarantees does X give when it comes to the order of events generated in relation to processing of the requests sent by the client? (Also, of course: To which degree does various implementations of X actually fulfill these guarantees?) It would be a major bug if any X server didn't order events correctly. It should be safe to rely on, though you mileage and level of cynicism may vary. X events have a serial value. I expect that any event delivered by X will reflect the state after the request number serial (and all preceding requests) have been processed. Is this correct? Can I also assume that the X event will reflect the state before any requests with a later serial number is processed? That is correct. The protocol spec says: Whether or not a server is implemented with internal concurrency, the overall effect must be as if individual requests are executed to completion in some serial order, and requests from a given connection must be executed in delivery order (that is, the total execution order is a shuffle of the individual streams). The execution of a request includes validating all arguments, collecting all data for any reply, and generating and queueing all required events. I was sure I remembered something like that, but I wasn't sure of the exact wording. I did notice this in my copy of the protocol spec (X Version 11, Release 6.9/7.0), though: [Almost all] core events [.. also contains the sequence number of ..] the last request issued by the client that was (or is currently being) processed by the server. Which makes me worry a bit that there is a possible loophole for the request with this particular sequence number to not be reflected in the event... (Though I suspect that's not the intended meaning of that sentence.) Given an application that frequently performs a sequence of XCopyArea() calls on the contents of a window. When this application receives Expose events or GraphicsExpose events, it is necessary for the application to know exactly which XCopyArea calls have taken effect to be able to correctly calculate which area of the window has become invalid. Right. GTK+ used to have (and likely still has) a scheme where a CopyArea generates an internal record that a piece of the window has moved at a certain serial number. These records are stored in a queue. Then, when an expose arrives, entries in the queue with a serial number before the expose are processed. If the area touched by the record intersects the area exposed, the expose is treated as if it exposed the region (original_rect - intersected_rectangle) + (translated intersected_rectangle) Yes, that was pretty much my plan. (Well, entries with serial numbers older than the expose event are discarded, and the expose event is adjusted for all the remaining entries...) Unless you have a similar mechanism, you will probably have to call XSync() after each XCopyArea() to ensure that the copying and associated exposes have been processed on the server, before procesing any exposes. That was my conclusion, yes. Thanks for validating my logic :) eirik ___ 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: Zapping the Xorg server
Peter Hutterer peter.hutte...@who-t.net writes:
On Thu, Aug 26, 2010 at 02:45:51AM +0200, Wolfgang Draxinger wrote:
[...]
I this particular case: I'm system administrator at my university's
student computer lab. Some students tend to lock their sessions,
(override-)configuring {x,gnome,k}screensaver not to allow opening a
new session AND in the background start lengthy computational jobs.
This is strictly disallowed by us. We got a job queue engine for that.
People are explicitly allowed to zap locked sessions, if it's
obvious, the user who used the machine last went for lunch or came in
in the morning, starting his job, coming back sometime in the evening.
Or people just forget to log out.
But it's the hogs I'm worried about. And since you can disable the Xkb
option for terminate, I'm pretty sure, those would eventually find it.
Allowing ordinary users to zap is allowed for two reasons: There's not
always an operator on shift who could sudo-pkill the session, and it's
also meant as some sort of education: Don't be a hog, and don't leave
your station with unsaved data.
if you rely on users to zap the session for CPU hogs, then I think the real
problem is elsewhere, but not in whether the user can change the XKB map or
not.
In general I agree, but I can see how it can be a useful and educational
strategy in this case. I might argue that there are better ways, but I
won't argue that this choice is unreasonable.
Of course, that implies that Wolfgang's case is truly a special case and
should not dictate general X behaviour. Probably the correct solution
to support this behaviour is that the university should use its own
version of the keyboard driver (evdev, I assume), which recognizes
ctl+alt+backspace and zaps the server.
eirik
___
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: How to know if a window has a menu , identify by WId ( was `Simple App to get window WId` )
Aaron Lewis aaron.lewis1...@gmail.com writes:
Hi,
Still for the last plasma-globalmenu , now i've got some ideas , i
could grab the last focused window by remembering WId , and only if that
window has a `menu' , that will change the variable `lastWid' ..
So , something like this ..
In globalmenu.h
private:
WId wid;
In globalmenu.cpp:
void GlobalMenu::windowChanged ( WId wid ) {
// If Window has a menu , remember lastWid;
if ( X11-hasMenu ( lastWid ) ) {
lastWid = wid;
}
}
So is there any API like X11-hasMenu ( WId wid ) ?
Unless I totally misunderstand what you are trying to do, probably not.
There is no way X can know whether some random painting commands is a
menu or not.
The X server only deals with windows (rectangular, potentially
overlapping areas on the screen), allowing an application to listen for
events happening to that window (mouse clicks, key presses,
resizes...) and to paint into that window (lines, circles, rectangles,
pixmaps...). A menu is an abstract concept entirely inside the
application.
Also, last focused window may not be quite as easy as you think. The
X input focus may not be on the top-level window. The most obvious
example of this is any application implementing the XEmbed protocol
(http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html)
And on the other hand, the menu may be painted in a window which is
not a top-level window...
(And note that WId is a Qt term and does not exist in X11.)
eirik
___
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: Simple application to get window WId ?
Aaron Lewis aaron.lewis1...@gmail.com writes: Hi, I'm currently working on a KDE application , plasma-globalmenu , which will make all GTK / Gnome application globally on XBar , but now i'm meeting a problem , so i need to write a simply application , which could help me detect the WId of a running window. Like , popup a mouse , let me click on something , and print a unique number (WId) , in decimal or hex , doesn't matter. Could anyone give a hand on this simple application ? It sounds like you want xwininfo. I think it's very basic , but i've never done pure X11 programming before , any guides is appreciated. If you want to code it yourself, both xwininfo and xprop do this, so you could look at how they do it. (It is probably a little harder than you might think, as you probably want the XID of the application window, and not any random subwindow or the root window or a window created by the window manager...) eirik ___ 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: way to detect to xserver-xorg version
Tias t...@ulyssis.org writes: Hey, In my program, I want to check that the xserver-xorg version is = 1.8.0. What way to do this is advised: At runtime using XVendorRelease(), or do there exist different releases with inconsistent numbering ? And should this be combined with a literal match on XServerVendor() ? At configuration time, PKG_CHECK_MODULES(XSERVER18, [xorg-server = 1.8.0], FOO=bar, FOO=baz). But what if you want to discriminate different versions, multiple PKG_CHECK_MODULES ? This would swamp the number of _LIBS and _CFLAGS options... Also, PKG_CHECK_EXSISTS() seems to ignore the version I provided, and always sets FOO=bar. This would probably be easier to answer if you gave some indication of why you think you should refuse people with different X servers to run or compile your application. eirik ___ 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: way to detect to xserver-xorg version
Tias t...@ulyssis.org writes: On 08/16/2010 07:55 AM, Eirik Byrkjeflot Anonsen wrote: Tiast...@ulyssis.org writes: Hey, In my program, I want to check that the xserver-xorg version is= 1.8.0. What way to do this is advised: [...] This would probably be easier to answer if you gave some indication of why you think you should refuse people with different X servers to run or compile your application. Its not about refusing, its about using features: if the xserver is 1.8 or higher, my application can write an example xorg.conf.d snippet, otherwise it has to explain a different way of making calibration values permanent. Ok, that makes some sense. Remember to add switches for overriding your heuristics :) xdpyinfo has a case-based section that calculates the release based on the XServerVendor() and XVendorRelease(). I'll guess I'll go for a similar approach of strstr(ServerVendor(dpy), X.Org) and VendorRelease(dpy) 1080. Sounds like a most likely to work approach, yes. eirik ___ 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: blocking gui process
John Tapsell johnf...@gmail.com writes: On 5 June 2010 12:07, Russell Shaw rjs...@netspace.net.au wrote: Constructing GUIs with a declarative language is all well and good for non-programmers and artistic types, but as soon as you want to create a custom action or widget such as eg a dynamically created tear-off menu, it's a total pain to dig into all kinds of parser/interpreter machinery, reverse engineer everything because it's rarely documented, and then actually do the task that should've taken 2 hours instead of 2 weeks or months. Forget UML XML CSS JAVA(SCRIPT) PYTHON C++ and all kinds of OOP crap and just write the fundamentals in non-OOP C. This is no easy task for someone starting out, but is a doable solution. You'll end up with a fraction of the code and infinite flexibility. Must we let Russell troll every user thread? :-/ I think his basic criticism of toolkits in general is quite valid. There is no doubt that simplifying abstractions can make it very hard to actually do anything the abstraction isn't specifically designed to handle. Which is particularly frustrating when you know exactly what you want to do on a low level. But (as has been pointed out before) his suggestion to write your own toolkit is horribly misguided (unless you have extremely limited requirements, such as only has to work for me). And his dismissal of a random set of more or less unrelated technologies seems borderline nonsensical. (He would rather use C than UML to explain abstract concepts to other people? He would rather write his user documentation in C than in XML+CSS? And what's that conflation of Java and JavaScript doing there anyway?) (And yes, I think declarative UI design is a good idea. But I don't know how to design such a system to provide both the simplicity and the flexibility you would want.) eirik ___ 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: C++/Shell Integration
Dirk Wallenstein hals...@t-online.de writes: On Sat, May 15, 2010 at 11:41:45PM +0100, Mubarak Aguye wrote: Hi. I was wondering if there is a way of determining the title of the current active window, and its x-y coordinates from within a C++ application, or even a standard Linux shell. For the shell, you could use 'xwininfo'. For C++, you would use XWindowAttributes and Properties. http://www.x.org/docs/X11/xlib.pdf (Chapter 3) http://tronche.com/gui/x/xlib/window-information/ And the currently active window, assuming you mean the window that is currently set up to receive key events from the primary keyboard, is probably the window you get from XGetInputFocus(). (If you mean something else by currently active window, you'll probably have to ask your window manager somehow.) eirik ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Opening a window without activating it
Andreas Falkenhahn andr...@airsoftsoftwair.de writes: Am Sunday 16 May 2010 schrieb Andreas Falkenhahn: I already checked out EWMH but I don't see any properties in that specification which could do what I want. read here: http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html set the InputHint to False, then map, then maybe set it to True (if you want to receive input focus by e.g. mouseclicks) Thanks, that does exactly what I want. That shouldn't be necessary, though. The only applications I know that takes focus when they start up are java applications. awt does an explicit XSetInputFocus() to itself when it creates a new window. So I think it is your window manager that is set up to automatically give focus to new windows (or as enlightenment 0.16 calls it: All new windows first get the focus) eirik ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ati Radeon 7200 3D feature is buggy (kernel 2.6.34-rc6, ATI driver 6.13) (Answer TWO: more precise)
Uwe Bugla uwe.bu...@gmx.de writes: Am Dienstag, den 04.05.2010, 07:49 +0200 schrieb Michel Dänzer: On Mon, 2010-05-03 at 21:50 +0200, Uwe Bugla wrote: [...] Dave's contribution contains a hunk 6 against radeon_object.c which is pure crap, as radeon_object.c is simply not long enough: 509 lines! This is the piece of crap (i. e. hunk 6) which should not be there: [...] The only 'crap' I've seen has been your uttering. If you're trying to make our killfiles, you're doing pretty good. Huh! What have I done? You referred to Dave Airlie's patches as crap without a sufficiently strong argument for choosing such harsh words. (The fact that it didn't apply cleanly to *your* tree is not sufficient.) If you choose to phrase your problems as insults against the people who are trying to help you, they will probably stop talking to you. eirik ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr dual-screen usability survery
Eeri Kask eeri.k...@inf.tu-dresden.de writes: Am 17 Feb 2010 12:38:16, Alex Deucher alexdeuc...@gmail.com schrieb: And aside from that, didn't you say earlier that the Intel driver actually has it removed and that it is official Xorg policy that keeping classic dual-screen alive is not intended? Yes, the intel driver has removed it. It's not policy to remove zaphod mode, but none of the active Xorg developers that I know of use it and very few users overall use it, so it doesn't get tested much. We are all busy so it's not a high priority. Is it correct to deduce, nvidia software engineers either (1) are not busy, or Which could simply mean that they have a larger ratio of developer resources to work items. (2) don't discriminate less widespread X11-technology use cases? This is certainly not true. Pretty much any driver team will discriminate against less widespread X11-technology use cases. As long as you have two or more things you want to do, it is a safe bet that one of them will have higher priority than the other. And I think it is a safe bet that widely used features will tend to have higher priority than little used features. There could also be technical reasons why it is easier to maintain zaphod mode in the nvidia driver. Maybe their architecture made it easy to implement proper xrandr support without breaking zaphod. Or maybe it's just that some of their engineers actually use zaphod and thus fixes the problems when they show up. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw rjs...@netspace.net.au writes: Dirk De Becker wrote: Tom, Thanks for the clarifying questions, since I had no clue what information John needs. The answers: - I want my program to be dominating the entire display (i.e. to be on top of all other graphics). Maybe later on, I will like to be able to switch between being inside a window and being on top of everything else, but for now, being on top of everything else will do just fine. - At present, I will not be changing the resolution (again, this will probably be added in the future). - I will not do 3D stuff, videos might be possible. To cover the whole screen, use the _NET_WM_STATE_FULLSCREEN state to maximize your X window. http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551694 To have unlimited power in 2D and 3D drawing, use openGL direct with Xlib: http://www.sv.vt.edu/classes/opengl/examples/porting/glxsimple.c Wow, a Mark Kilgard example that doesn't use GLUT :) (Of course, it is using an old, outdated OpenGL version.) Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. I think opinions are somewhat divided on that point. A good toolkit lets you do pretty much anything you want with much less work, and no significant performance cost. (Frequently with higher performance, as someone has probably spent a fair bit of effort investigating how to get optimal performance out of the underlying system.) A good toolkit will also often do the right thing on other people's computers, whereas your own code tends to work correctly only on your own computer. (One of the basic rules of programming: If it isn't tested, it doesn't work.) And it will typically be updated to take advantage of new features in the future, making your program still work and sometimes work better. The main problem (as with all abstractions) is that if you know exactly what you want to do in the low-level layer (e.g. X11), it can be very hard to figure out how to do that from higher up. And it can take some time for interesting new features to be supported. (That being said, I tend to favour using X11 and OpenGL directly myself...) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Force destroy Widget
LALLIER Cedric (EXT TEAMLOG) ext.teamlog.cedric.lall...@sncf.fr 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: building of xrandr against uClibc
Adam Jackson a...@nwnk.net writes: On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote: Hi all, can anyone fix compiling of xrandr against uClibc (reported in http://bugs.freedesktop.org/show_bug.cgi?id=12958) see also: http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html http://lists.x.org/archives/xorg-devel/2009-February/000281.html http://bugs.gentoo.org/197013 http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html Pretty sure this is a uclibc header bug. glibc has exactly the same definitions in bits/sched.h and does not have this problem. Which I already said the last time this was brought up: http://lists.x.org/archives/xorg-devel/2009-March/000365.html - ajax If you think that it is a bug in the uclibc headers to declare the clone() function at all, your argument is valid. However, I think the comment in the bug (why cant this symbol get renamed so that things compile?) is also valid (regardless of who is at fault). Renaming the enum value to avoid the potential conflict may be the better option anyway... And I don't think glibc's behaviour is a normative reference :) (If someone could find a specification that clearly says whether it is disallowed to declare clone(), that would be nice...) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: building of xrandr against uClibc
walter harms wha...@bfs.de writes: Eirik Byrkjeflot Anonsen schrieb: Adam Jackson a...@nwnk.net writes: On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote: Hi all, can anyone fix compiling of xrandr against uClibc (reported in http://bugs.freedesktop.org/show_bug.cgi?id=12958) see also: http://osdir.com/ml/linux.lfs.hardened/2008-04/msg9.html http://lists.x.org/archives/xorg-devel/2009-February/000281.html http://bugs.gentoo.org/197013 http://www.mail-archive.com/hlfs-...@linuxfromscratch.org/msg02003.html Pretty sure this is a uclibc header bug. glibc has exactly the same definitions in bits/sched.h and does not have this problem. Which I already said the last time this was brought up: http://lists.x.org/archives/xorg-devel/2009-March/000365.html - ajax If you think that it is a bug in the uclibc headers to declare the clone() function at all, your argument is valid. However, I think the comment in the bug (why cant this symbol get renamed so that things compile?) is also valid (regardless of who is at fault). Renaming the enum value to avoid the potential conflict may be the better option anyway... And I don't think glibc's behaviour is a normative reference :) (If someone could find a specification that clearly says whether it is disallowed to declare clone(), that would be nice...) I have no clue where clone is coming but you may like to know: glibc/linux also has a syscall called clone, who is that handled ? Two possibilities: 1: The relevant header file does not get included when using glibc. 2: glibc only declares this function if requested. The man page seems to indicate that 2 is true (You need to #define _GNU_SOURCE). But Mikhail's response indicates that 1 is true. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Kai-Uwe Behrmann k...@gmx.de writes: My application attaches a XFixes created reactangle to a window. Therefore it does a XOpenDisplay() + XFixesCreateRegion() + XCloseDisplay() inside one short function and done. After the above outlined function resturns a call to XFixesFetchRegion() from a outside observer forces the application to quit: PropertyNotify : _NET_COLOR_REGIONSv 679x580+642+245 2 X Error of failed request: 179 Major opcode of failed request: 155 (XFIXES) Minor opcode of failed request: 19 (XFixesFetchRegion) Serial number of failed request: 7927 Current serial number in output stream: 7927 Any idea how to avoid a quit from XFixesFetchRegion()? A error message would be enough. A exit in not acceptable to the application. My memory is rather unclear on this point, but if the default error handler exits the program, the solution could be to install your own error handler with XSetErrorHandler() eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XI2 pull warning
Thomas Jaeger thjae...@gmail.com writes: I've posted a build log (make -j4) here: http://pastebin.com/f3f965926 The more I think about it, the more it becomes clear to me that a recursive call to make can never do the right thing during a parallel build. Tom Of course it can. But if you have cross-module dependencies (and you probably do), then it can be quite painful to get it right (and even worse to maintain it). The canonical reference is of course recursive make considered harmful. eirik Dan Nicholson wrote: On Tue, Jun 2, 2009 at 8:24 AM, Thomas Jaeger thjae...@gmail.com wrote: Peter Hutterer wrote: actually, the reason for this could be a missing dependency in the man pages. If you can reproduce this error, just check the Makefile.am for the dependency setup for the file it fails on. I've tried triggering it but without success. My theory is that it's a race condition, where due to the recursive call of make the same man page is built at the same time by both processes and then the second mv fails. Can you show the error? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [OT] Re: libxcb-xlib.la failures when building X11 with libxcb-1.2
Simon Thum simon.t...@gmx.de writes: Bill Crawford wrote: included on the command line at link time. Libtool sort of abstracts this, but to do so it needs to keep track of what those dependencies are, and does so by storing them in this .la file. Thanks for the explanation. What baffles me is that AFAICT this introduces a lot of names to the linker, which you hadn't in mind when programming. So this practice is dangerous, because if you misspell something it may still be satisfied as libnever-heard-or-seen.so provides just your typo as a symbol, suppressing the proper error. That's correct. However, the likelihood of such misspellings are fairly small as long as the shared objects use a reasonable naming convention. This is complicated by the traditional export-everything policy of unix toolchains, though. Although, in C/C++ such an error would also mean that the misspelling matched some header file as well. So when this happens I don't think the link-time match is your main problem :) On the other hand. I think it is a much bigger problem that two libraries may in fact export the same name. Now that really causes problems, as you may get a completely different function than you expected even though you spelled it correctly. Or, when the (load-time) dependency tree of libraries ends up pulling in mutually incompatible libraries (like when opera depended on on one version of libpng, and libqt depended on a different version). eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: clarification requested: apparent termination of xrx project due to deletion of lbx from xorg
Luke Kenneth Casson Leighton l...@lkcl.net writes: i really _really_ want to fire up _specific_ locally-hosted applications, to run locally, as controlled by and specified by some javascript application running in web browser, to run _in_ the existing x server. order of events: 1) user fires up X-windows, and runs _one_ application: a web browser. full screen. no menus. nothing but total exclusive domination of the screen. no window manager. nothing. 2) web browser runs _one_ web page - a window manager, written in javascript. 3) window manager, written in javascript, gets a click on an icon which says run xclock. 4) javascript code dynamically creates a node (something like this) embed type=x-application/embedded-xapp params=/usr/bin/xclock width=100 height=100 / and adds that node to the browser DOM model (location is chosen by the javascript-implemented window manager) 5) NPAPI-compliant plugin (it can't be rxr because that's borked) fires up xclock as the sole, exclusive, _only_ application to run *inside* the web browser. You do realize that this is NOT a window manager? A window manager is supposed to handle all windows created on the given display, regardless of how they are created (notwithstanding override-redirect, of course...). And the ability to launch applications isn't part of the window manager's job (though a window manager may of course provide that feature if it wants to). What you are describing is exactly what plugger tries to do (well, the plug-in part anyway). Except that plugger will only launch the applications that has been described in its configuration files, rather than letting the attacker decide what application to run on your computer. The other reason why plugger needs a configuration file is that it needs to know how to deal with each application. In particular, it needs to know how to find the application's window (either to have the application use a subwindow controlled by plugger, or to reparent the application's window). There's really no well-defined way to do what you (and plugger) wants to do. For the most obvious questions: How are you planning to deal with dialogs? Or applications that open multiple windows (e.g. gimp)? Or no windows (e.g. rm -rf /)? eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems configuring AsusTek VW161D with 1366x768x16M
Bill Crawford billcrawford1...@gmail.com writes: On Wednesday 11 March 2009 08:11:43 Tino Keitel wrote: As LCDs usually like vertical refresh rates of 60 Hz, you also shouldn't use a 75 Hz mode. Most LCDs seem to be capable of 75, and I (alone?) can see the difference, at least on my Hanns·G monitors at work. Assuming that your lcd has a stable backlight and the displayed image does not change, the signal refresh rate should not make any difference at all. If the backlight is flickering on the signal refresh rate, there's a fair chance that many people will be able to tell the difference between 60 Hz and 75 Hz. On the other hand, if the backlight is flickering at twice the signal refresh rate or more, it should be quite hard to notice for most people. Using a changing image, it should be possible to design a movie that many people with perceive as smoother at 75 Hz than 60 Hz, where the effect is completely unrelated to sampling artifacts. (Using sampling artifacts, it is also possible to make 60 Hz seem smoother than 75 Hz, which is why I specifically mention that). However, this depends on the panel refresh rate being synchronized with the signal refresh rate. My old lcd monitor (which is now my secondary monitor) would drop ca 1 frame per second when the signal refresh rate was ~60 Hz. So I'm suspecting that the panel refresh rate was decoupled from the signal refresh rate on that particular monitor. I don't know how common that is, though. (And admittedly, I haven't tried varying the signal refresh rate to see what happens.) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XtDisplayToApplicationContext fails with Error: Couldn't find per display information
Glynn Clements gl...@gclements.plus.com writes: Tristan Schmelcher wrote: Hello all. Sorry if this is not the right place to send this, but I'm developing a plugin for Firefox on Linux and I've run up against a roadblock. In my plugin I'm being passed a pointer to an X Display struct (in NPP_SetWindow, for those of you that know NPAPI) and I'm calling XtDisplayToApplicationContext on it to get an app context to use in various Xt calls. Now on most systems this works fine--e.g., Ubuntu Dapper 32-bit with FF2 and Intrepid 32-bit with FF3 both work flawlessly. However, when I build a 64-bit version and try it on Ubuntu Hardy 64-bit with FF3, it doesn't work. When it enters XtDisplayToApplicationContext, I get Error: Couldn't find per display information on the console and the program exits. Does anyone know what could be causing this function to fail? I searched the web but without luck. AFAIK, the display must have been registered with Xt via XtDisplayInitialize(). With a conventional Xt-based application, this is done by e.g. XtAppInitialize(). Firefox isn't an Xt application, so I'm a bit surprised that it works at all. However, digging deeper I see that libxul.so uses Xt: This is a requirement in the netscape plug-in api. It passes a window that is documented to be an XmDrawingArea to the plug-in. However, most browsers ignore that and uses a plain Xt window instead. Obviously, the plug-in itself needs some way of accessing the window and receiving events. Painting can be done with plain X, but in order to receive events, the plug-in must register with the browser's main loop. So the only reasonable thing to do is to use Xt. (Yes, the netscape plug-in api is broken by design. The windowless style is slightly less broken, though.) eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: bug in xfont xlfd rounding code
Dave Airlie airl...@gmail.com writes: Hi guys, Maybe someone understand wtf the code in libXfont/util/fontxlfd.c:xlfd_round_double is all about, but the results were different on different endian machines due to the code being hardcoded for little endian. Which is to say x86 layout. I reimplemented it for other endian, however I'm unsure about the endian detect code on other OSes, it just uses the autoconf macros. I'm not convinced that floating point layout is a plain big/little endianness that follows the integer endianness. But it's been some time since I had to worry about that... eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXrender - documentation?
Clemens Eisserer linuxhi...@gmail.com writes: [...] For sure the Opera/QT combination is not doing anything like that - all the calls that actually pass glyphs to/from the server use good ol' Xlib. Though there is evidence that xft does use Xrender elsewhere in its workings. I don't know about opera, but im am pretty (99,5%) sure QT uses Render - now if Opera uses QT's graphic context for drawing it will implicitly use it. The text handling in Qt 2 was abysmal (in particular the font switching), so we (opera) implemented our own. I don't think we've changed it much since then. I believe our implementation uses xft and classic x fonts directly. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg segfaults on XOpenDisplay multi thread
Matan Drori ma...@graphtech.co.il writes: Machine spec: IA64 /SUSE Linux Enterprise Server/ 10 sp 2 xorg x11 6.9.0-50.58 I have a very simple test program that opens 4 threads and does XOpenDisplay(opening 4 separate display objects). i keep getting segfaults on different places in the function seems like some kind timing problem that causes memory corruption. You have called XInitThreads? (See man XInitThreads) (I don't know how thread-safe xorg is. I have the impression that there are some issues. But without XInitThreads(), it isn't supposed to be thread-safe). eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X12
Nicolas Mailhot nicolas.mail...@laposte.net writes: Le Jeu 18 décembre 2008 17:08, Eirik Byrkjeflot Anonsen a écrit : Nicolas Mailhot nicolas.mail...@laposte.net writes: Hi, I hope that when XI and XKB are reworked a language property will be added to the protocol. Right now many apps try to infer the language being written from the xkb layout in use (for on the fly spellchecking, activation of the correct locl font features, etc) and since the same layout can be used to write different languages the heuristic breaks badly. In which cases should this differ from the system locale? (I.e. whatever setlocale() returns). When someone writes an English message to an international list, for example. Thomas Ilnseher il...@gmx.de writes: The Problem is IIRC that this locale stuff uses environment variables (ie. LANG, LC_ALL, etc ...). This stuff is placed on the stack of a new process when execve is called, and can't be changed at runtime. Ah, I see. The problem is when there is something outside the application that wants to change the current locale of the application. If the application itself wants to change the language, it obviously knows which language it works in (emacs does that, which is how I do japanese, norwegian etc.) The problem with that is that the support must be built into each application, which also means that each application behaves differently. It seems to me that this is only about text input. In general I would assume that only the user's current text input language is what is particularly useful to change frequently. So this would be part of internationalized text input, otherwise knows as input methods. To the extent that X has support for input methods, I think it makes some sense to be able to ask the input method subsystem of X what language is the user currently typing in. But then again, maybe input method handling should be decoupled from X completely. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X12
Nicolas Mailhot nicolas.mail...@laposte.net writes: Hi, I hope that when XI and XKB are reworked a language property will be added to the protocol. Right now many apps try to infer the language being written from the xkb layout in use (for on the fly spellchecking, activation of the correct locl font features, etc) and since the same layout can be used to write different languages the heuristic breaks badly. In which cases should this differ from the system locale? (I.e. whatever setlocale() returns). eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Getting xorg-7.4 from git ?
Donnie Berkholz [EMAIL PROTECTED] writes: On 08:27 Fri 26 Sep , Carl Worth wrote: On Fri, 2008-09-26 at 01:14 -0700, David Sharp wrote: this could be made easier by tagging releases for the katamari with a common tag, like Xorg-7.4 And even easier with a super-module repository that would just need one tag. Didn't Zack even prototype such a thing once? Has anyone looked into how reasonable it would be to use such a thing for releases? I've heard some claim that the supermodule approach wouldn't work well for just tracking the latest development at the tip of all the master branches, but it sounds perfect for tracking releases. When git folks added submodule support, somehow they managed to miss the (obvious to me) use case of tracking all the submodule HEADs instead of sticking to specific commits. It was even discussed in the thread where the patch was proposed, and an early version of the patch did track HEADs. If this is a blocker, it shouldn't be much work to add a flag for it. I thought it was strange at first, too. But once I had thought about it, I came to the conclusion that the current behaviour is what you want. What you'll realize when you understand the various use cases is that there is no truly correct behaviour. And the current one is probably the one with the least nasty surprises. For example, in the correct case where all the submodules are truly independent projects, you don't want magic dependencies between the tags/branches in those (independent) projects. It's just nasty. Consider checking out master of the supermodule. If you get the revisions of the submodule that was actually used when master on the supermodule was checked in, it works as intended. But if you instead get the master branches of the submodules, all bets are off. The alternative, making special branches in the submodule for the supermodule, is obviously getting the dependencies between modules turned the wrong way around (the submodule should not need to know that it is used by the supermodule). The use case for doing it differently is when the git repos are not independent projects, but a single project split into small pieces. I guess in the case of X, many of the modules makes little sense outside of X. But that is not the use case that git submodule support is designed to solve. And I would say it is not the most important use case to handle. The submodule support in git has many problems. Everybody knows it, but I think the git people are worried about breaking it beyond repair. Which seems to be a sensible approach right now. eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
