Re: Securing non-root X input
On Sun, Jan 31, 2010 at 5:13 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Sat, Jan 30, 2010 at 06:35:47PM -0700, Matthew Wilcox wrote: On Fri, Jan 29, 2010 at 11:45:46PM -0800, Dmitry Torokhov wrote: Hi Matthew, On Fri, Jan 29, 2010 at 04:24:38PM -0700, Matthew Wilcox wrote: This tiny patch allows the X server to ask how many times the device has been opened. If it's more than one, the X server can ask the user what they want to do about it. For bonus points, the X server can also run programs like lsof or fuser to find out which other processes have the device open, and tell the user that information too. At that point, the sysadmin can call in the ICBM strike on the offending user. Does this approach work for everyone? I do not think so. What about the cases when event devices are legitimately opened by several processes, like this: [d...@dtor-d630 work]$ ps aux | grep hald-addon-input root 1132 0.0 0.0 22200 824 ? S Jan22 0:29 hald-addon-input: Listening on /dev/input/event7 /dev/input/event2 /dev/input/event1 /dev/input/event6 /dev/input/event0 /dev/input/event12 /dev/input/event4 dtor 30424 0.0 0.0 102736 808 pts/3 S+ 23:23 0:00 grep hald-addon-input [d...@dtor-d630 work]$ It might not be hald but some other daemon monitoring key presses (sleep, hibernate, wifi keys and switches, etc). If it was just about ensuring that only oneprocess accesses the device then we could just use EVIOCGRAB but as experience shows it is not a workable solution. Yes, that's right. I didn't quite go far enough in my explanation above ... the X server can look around the system to see what trusted daemons (running as either root or the same user as the one running X) currently have the device open, and notify the user if there's additional openers that it isn't expecting. Then it will be constant race between X and the rest of the world with X pretty much always behind. Kind of like SELinux - as soon as try moving left or right the thing starts screaming at you... Maybe we don't need a kernel patch to make this work after all, just a suid helper for X that uses the code from lsof/fuser to list all the current openers of /dev/input/eventN. But what about the case where malicious user opens the devices after the X done its scan? That can't happen since we remove privs from the previous users of the node before starting the new X server via ConsoleKit or at least thats the plan, The problem is only a user holding open the evdev device after they've lost perms on the device. Dave. mknod is a privileged operation, requiring CAP_MKNOD. Otherwise evcen current setup would be completely insecure if any user could just mknod in his home directory and snoop root's keypresses at console. Its more the other devices the kernel might make, or udev. Not sure if that ever happens though. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Slow 2D with radeon KMS
On Sat, 30 Jan 2010 15:35:44 +0100 (CET) Damien Mir mailings.x...@mirabel-sil.com wrote: Hi, I just tried KMS with radeon driver, and 2D seems notably slow. Widgets takes time to draw, scrolling in Dolphin or Firefox lags, as if some 2D acceleration was not working alright. I use radeon KMS on an R600 (HD 3870) and all works really well. 2D as well as 3D (glxgear, tuxracer, nexuiz). Kernel is 2.6.32 and drm, mesa, xf86-video-ati are latest git HEAD. Maybe you need a newer version of the ati driver. harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xfbdev: no screens found
Could somebody please tell me how to convert the information from fbset -i to a modeline suitable for hw/kdrive/src/kmode.c? I've a ARM9 board (mini2440) but I cannot get Xfbdev running. # fbset -i mode 240x320-66 # D: 5.882 MHz, H: 21.626 kHz, V: 65.733 Hz geometry 240 320 240 320 16 timings 17 1 26 2 5 5 2 rgba 5/11,6/5,5/0,0/0 endmode Frame buffer device information: Name: s3c2410fb Address : 0x3394 Size: 153600 Type: PACKED PIXELS Visual : TRUECOLOR XPanStep: 0 YPanStep: 0 YWrapStep : 0 LineLength : 480 Accelerator : No # # Xfbdev -screen 240x320x16 -rgba rgb Warning: mode not found, using default error: Invalid argument Fatal server error: no screens found # Nik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular build, libGL make install fails
On Sat, Jan 30, 2010 at 3:17 PM, David Gerard dger...@gmail.com 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 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? 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. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: modular build, libGL make install fails
Mm. I thought it was relevant to here since it's a mandatory part of building Xorg at all. - If you're using the nVidia binary driver you can skip(cut it out of the xorg.modules) the mesa build because nVidia binary uses it's own Glx modules. Remember to put --disable-glx in the autogenargs for xserver in xorg.modules. Also take out the stuff you don't need to build in the xorg.modules which will save you time and headaches. If you're unsure just use the mesa-dev packages in whatever distro you're using. 'sudo ~/.local/bin/jhbuild --moduleset=/home/foo/jhbuild/modulesets/xorg.modules -f ~/jhbuildrc.XORG build xorg' works for me. Happy Building. ubuntu 9.10 - Error:Success -- View this message in context: http://old.nabble.com/modular-build%2C-libGL-%22make-install%22-fails-tp27388491p27394454.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. All that is done to a degree. Theming engine allows apps to look and act like any other system. Once you architect the full depth of the problem with minimal things that work at every stage, you can add more parallelable features whenever required. OK, sounds like it should be pretty easy for you to knock up? Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Would you like a ctrl-shift+triple-middle-click popup menu? I only make useability different if i know it's the right thing to do. No, I just want double-clicking to work. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. I didn't say it would be unconditionally easy, but to solve an immediate engineering problem of drawing to a full screen and having a menu, Xlib + OpenGL + Glut is fairly easy. I assume their requirements will eventually run deeper than 'full screen, one menu'. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. No, it's not useful innovation at all. All the answers to do anything you want is available on the web, email lists, and in books. It's definitely not quick and easy to do the whole thing. No, hence why someone asking how to do something eye-wateringly simple, we should recommend they use existing toolkits. I wouldn't be recommending any of this if i found existing widget toolkits easy to make new non-trivial widgets that run well. I've battled widget toolkits since Windows95. The code for various existing X toolkits is inpenetrable, and made overly complex for porting to non-X systems that i don't require. Having thought through many problems, these codebases can be more comprehensible, but what's the use when one has had to figure out how to make a toolkit in order to figure out how to fix one? He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. pgpYiEtHHmsQd.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) - Clemens 2010/1/30 Russell Shaw rjs...@netspace.net.au: Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. Not directly. In the context of widget kits, pointer dereferences often hide from the programmer what low level function is being called, especially when there's multiple levels. More of a pain to understand and write code knowing it will run well (sigh broken record). feature-bare toolkits. Which features are you missing from current toolkits? Foolproof multithreading. I should be able to easily have two windows being updated from different threads without interaction problems due to static vars in the toolkit. Until relatively recently, various toolkits had no kind of centralized hot-button help system that i could find. It's way too hard to make a new non-trivial widget when it should be much easier. Many widgets have performance problems when you want to scroll through 10k items from a database. I'm sure they can be made to work well with enough detailed knowledge of the widget, but to get that far, i had to figure out how widgets and everything should work because of lack of know how and documentation. Makes a toolkit rather pointless when the barrier to being productive is that high. I should be able to fork and exec from within a GUI program without problems. A gui framework baggage that comes with widgets should be minor in memory cost. Last time i was using gtk, there was no definitive way of parsing configuration files (tho there is now i think). I wanted ligatures and proper kerning in fonts. I wanted access to all the features in a truetype font file. Last i looked, pango had little documentation about using it in great or sufficient detail. Not knowing anything about non-english text, i had no hope of even knowing what to ask about pango. A simple block diagram of how it processes utf8 clusters would have gone a *long* way. Some explanation of what's in a font file and what contextual analysis is would have helped a lot. I wanted more control over hints for the window manager. That may have already existed, but there was no overview documentation in gtk about that years ago when i used it. I had to learn all the fine details of Xlib and icccm just to figure out what questions to ask. I wanted printer support. I know now that's rather vague and out of scope for widgets. There were no gtk docs explaining that. I used to be using the printer GDI in windows. There was no support for widget settings persistance, or docs saying what to do about it. If i last used a file dialog on a certain directory, i wanted it to open there next time i used the program. I know what i should do in my own way now. There was no drawing support in gtk other than gdk which i found over a year later was xlib calls. Ran slow as hell. Could use cairo now, but i stick closer to the metal and use opengl or shm images. Cairo can draw to a printer context iirc, but i'd rather just generate postscript output directly. I wanted to have accurate colour management, but i see that as out of scope of widgets now. I wanted to programmatically generate menus on the fly that adapt to the results of database retrieval based on ealier stages of the menu hierarchy. At some point gtk changed to XML files to define menus. That totally pissed me off and was when i abandoned gtk. I wanted to do window-in-window mdi. Any mention leads to howls of denial that you don't need it or it's unuseable because you can't use the app on a dual-head setup. Well, i wanted to just a drag an embedded mdi document with a mouse so that it magically becomes a top-level window. Likewise, i could drag it over the mdi container and it would become re-embedded and managed by the mdi window manager. I wanted to have a widget that acts as a window manager complete with icon handling. Then i could use a family of related applications within that shell widget, and have them all appear there in the same state next time i log on. I wanted to make independent X apps such as editors become embedded in my own widgets. I still think about that area. I wanted the whole thing to run well on a 10MHz 8-bit cpu. It still would if i omit scaleable shaded 3D buttons and do another suitable small windowing system. Memory limits for a full unicode font and various window buffers would be pushing it a bit. I still aim for that efficiency. I've read the qt book and tried qt and read the stroustrop book multiple times and know everything about C++ but remain unimpressed at the complexity
Re: X11 fullscreen
On Sun, 31 Jan 2010, Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. I don't understand your point. I think it would be great if GTK supported all the features he mentioned. (Incidentally, I think I heard someone mention that GTK3 would use the same primitives for drawing on the screen and on the printer, so that might be a step in the right direction). :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. All that is done to a degree. Theming engine allows apps to look and act like any other system. Once you architect the full depth of the problem with minimal things that work at every stage, you can add more parallelable features whenever required. OK, sounds like it should be pretty easy for you to knock up? It works, but needs refining. I shouldn't use Theming engine. That's a programmer wankword for some kind of state machine. I do theming with a simple plugin api. Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Would you like a ctrl-shift+triple-middle-click popup menu? I only make useability different if i know it's the right thing to do. No, I just want double-clicking to work. It works. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. I didn't say it would be unconditionally easy, but to solve an immediate engineering problem of drawing to a full screen and having a menu, Xlib + OpenGL + Glut is fairly easy. I assume their requirements will eventually run deeper than 'full screen, one menu'. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. No, it's not useful innovation at all. Why? Try scrolling a list with 1e6 elements with ease. All the answers to do anything you want is available on the web, email lists, and in books. It's definitely not quick and easy to do the whole thing. No, hence why someone asking how to do something eye-wateringly simple, we should recommend they use existing toolkits. All the answers exist, but any low-grade resource needs searching and refining. That's why toolkits exist. All the answers in one spot. Sometimes they're not suitable answers. I wouldn't be recommending any of this if i found existing widget toolkits easy to make new non-trivial widgets that run well. I've battled widget toolkits since Windows95. The code for various existing X toolkits is inpenetrable, and made overly complex for porting to non-X systems that i don't require. Having thought through many problems, these codebases can be more comprehensible, but what's the use when one has had to figure out how to make a toolkit in order to figure out how to fix one? He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to just use a toolkit when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) What do you suggest? I'd very much like to know. How do other toolkits draw widgets? I haven't bothered looking for a long time. I have found no performance problems with shm ximage for the way i use it. The results look no different to any other toolkit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw wrote: Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: ... He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to just use a toolkit when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. Cairo in gtk may be useable to a degree. I still see reports of speed problems. It is too high-level for me. It has an advantage of drawing to multiple contexts such as a printer or pdf etc. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) What do you suggest? I'd very much like to know. How do other toolkits draw widgets? I haven't bothered looking for a long time. I tried and battled XRender for some time. It was poorly documented to the point that it hardly seems like it was intended to be used by anyone generally. It also had bugs when i used it. Gtk uses it iirc, but i won't touch it now. I did read the source in X server. Glitz and other stuff wasn't a lot of use. I just use opengl if i need much acceleration. I have found no performance problems with shm ximage for the way i use it. The results look no different to any other toolkit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: silly keycode question
On Sun, Jan 24, 2010 at 01:49:36PM +0100, Tom Cowell wrote: In my experiments, I didn't want to do what Glynn suggested because I will be repeatedly changing the grabbed keys during the lifetime of the program. All the calls to XGrabKey seemed like a lot of overhead to me. So I did something different: my program is, for other reasons, using the Xkb extension, and processing XkbStateNotifyEvent to track the state of modifier keys. When Ctrl is pressed I grab the keys I want with AnyModifier, and when it is released I release them. This works for me, but I don't like it, so I think I will probably try what Glynn has suggested. it has an inherent race condition in that the key is not grabbed in between delivering the event and your client re-grabbing the key. Plus, there's the issue that if another client has a grab on the same key you'll run into issues with AnyModifier. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: MIDI driver for xorg?
On Mon, Jan 25, 2010 at 11:03:40AM +0100, Crypto wrote: I'm new to this list and I would like to know if there is a MIDI driver for the xorg xserver. Before you think my, that's a silly question for a starter... let me describe why I think that there could actually be very good reasons for that. 1.) MIDI interfaces connect to PCs typically via USB or joystick port. The USB connectivity is similar to that standard USB computer keyboards. From that interface-based point of view they do not differ much from ordinary keyboards. 2.) MIDI devices transmit data at rather low speed in short commands in a byte-wise language which includes not only commands (e.g. NOTE ON/OFF) but also stream data for some musical events. This again is similar to ordinary keyboards. 3.) If a GUI of an application was able to understand incoming MIDI events it could be remotely controlled via MIDI interface, aside with mouse and keyboard. This is actually my main reason for writing this - I have found that there are really few applications out there that have a) a GUI, b) can be fully MIDI controlled. In most cases it would be a question of selecting a menu entry using MIDI commands instead of an F-key or mouse button, so it looks like it could be done by making MIDI commands known to the shortcut tools of applications, thus by implementing a MIDI xorg driver. Maybe it is mainly a question of real-time capabilities of the underlying hardware driver it could not be done yet, but maybe there are/have been other good reasons for not having a MIDI xorg-driver? the balance between amount of work required and the usefulness of such drivers is a bit tilted :) you could write a driver that converts MIDI commands into key presses but that may not get past the point of a proof of concept. You'll likely run into issues regarding on-the-fly reconfiguration etc. forwarding MIDI through X to clients doesn't really work, the protocol doesn't cater for this. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
