Re: [ANNOUNCE] libXi 1.4.99.1
On 09/11/11 12:16, Peter Hutterer wrote: A month late but I just noticed that I never sent an announcement out for this. libXi is the first snapshot for XI 2.1 support. At this point I consider it unlikely that any major protocol changes will happen to the smooth scrolling support. If you're working on a toolkit or similar, I highly recommend to start using the new stuff while we can still change it to fit your expectations better. Hi, I posted this message 4-Nov-2010: quote In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. unquote I'm not currently working on mouse stuff, but i will again sometime, and will use more than one pointer device simultaneously for CAD programs. Brand and model number and also the port the pointer is plugged into would be useful, in case both devices are the same model. ___ 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
Dri2 buffer format
Hi,
How should the format of a DRI2 buffer be determined?
http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
DRI2ATTACH_FORMAT { attachment: CARD32
format: CARD32 }
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.
xorg-server-1.7.7/hw/xfree86/dri2/dri2ext.c
If it's opaque, how does a user or library know what bytes are red/green/blue
so that you can draw a line in the right colour?
___
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: XInput
On 05/11/10 10:21, Peter Hutterer wrote: On Thu, Nov 04, 2010 at 10:35:29PM +1100, Russell Shaw wrote: In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? no, the device ID is unfortunately the only identifier you have. model/vendor information, etc. isn't exported by any driver yet. Cheers, Peter When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. Hi, A unique ID would be useful. I found this in linux-2.6.31.1/drivers/input/evdev.c: if (_IOC_NR(cmd) == _IOC_NR(EVIOCGUNIQ(0))) return str_to_user(dev-uniq, _IOC_SIZE(cmd), p); It was not clear how to integrate it in to xf86-input-evdev/src/evdev.c When i start a program that uses a left-hand puck (i'm using a mouse) and a normal right-hand mouse, i'll have to make a pop-up widget appear every time so that the user can choose which mouse does what. It would be good if the application can store the settings for a unique device id. I used to use this mouse and puck arrangement around 1990 on a Human Interface Loop Bus (HIL Bus) on a HP 9000 Apollo workstation. It was a standard way of running CAD programs and greatly reduced mouse-finger fatigue. The software was killed for political reasons, but the useability was far better than the toy Windows stuff around now. http://wiki.parisc-linux.org/HIL ___ 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: Slow Radeon on upgrade
Justin P. Mattock wrote: On 11/02/2010 10:42 PM, Russell Shaw wrote: I commented out all of xorg.conf, but it didn't fix it. maybe try the ati driver instead of the radeonhd? Hi, I messed around with xorg.conf settings and tried reinstalling the old driver and xorg-core resulting in a locked pc at bootup. After unsetting various things and rinstalling stuff, i just got it to boot up with the new xorg and driver and now everything's running fast. Don't know what caused that. ___ 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: Slow Radeon on upgrade
I commented out all of xorg.conf, but it didn't fix it. ___ 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 properly use XGrabKey to get a program hotkey
cheshirekow wrote: Hello, My goal is to have a program that sleeps in the background but can be activated by the user via some hotkey. From digging around the Xlib manual and the Xlib O'reilly manual, I gather that the correct way to to this is with XGrabKey. However my understanding of the process is incorrect as a simple proof of concept does not work. My understanding is that if I call XGrabKey with the root window as the grab_window, and owner_events false, then whenever my hotkey is pressed the event will be sent *only* to the root window. If I then select KeyPress events from the root window, and then listen for X events, I should get a key press event when the hotkey is pressed. I've pasted a minimal example below. What I expect is that when the program is run, regardless of what window has focus, if Ctrl+Shift+K is pressed, my program should output Hot key pressed! in the console, and then terminate. Furthermore, it is my understanding that if the XGrabKey fails, the default error handler will display a message, and since it does not I am assuming that the call succeeds. Obviously, my understanding is flawed somehow. Can anyone point me in the right direction? This will only work if the window manager or the window with focus doesn't already grab the same keys. Does the example work without a window manager running? ___ 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: Fullscreen windows - weird behaviour
Andreas Falkenhahn wrote: Andreas Falkenhahn wrote: Hi, I have the following setup: ... Anybody got a clue what's going on there? You could add test code that uses XQueryTree() to find out why. http://tronche.com/gui/x/xlib/window-information/XQueryTree.html Hmm, I'm not sure if this would help. What is really confusing me is the fact that even when I call XGrabPointer() on my main window (mode set to GrabModeAsync), I can still get the task bar to pop up. How can this happen? Isn't XGrabPointer() supposed to intercept delivery of all mouse events excepting the window specified in XGrabPointer()? When I call XGrabPointer() without changing the screen mode using XF86VidModeSwitchToMode() it works exactly like that: Everything on the desktop except my window seems frozen. Clicking on the taskbar doesn't trigger any action. It's completely dead. However, when calling XGrabPointer() after XF86VidModeSwitchToMode(), it's possible to pop the task bar to the front. It's pretty weird because I thought that after XGrabPointer() the mouse would be completely mine until I call XUngrabPointer(). Does XGrabPointer() return GrabSuccess? It won't if something else has grabbed it. http://tronche.com/gui/x/xlib/input/XGrabPointer.html ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with X.org and incompatibilities with in-house software
Richard Brown wrote: Mikhail Gusarov wrote: Twas brillig at 19:05:25 28.02.2010 UTC-05 when rbrown1...@gmail.com did gyre and gimble: RB So of these disabled, removed extensions. How many of these are RB disabled as a result of actual broken code, vs, how many are RB disabled because, we don't like how it looks? Most of them were removed because they were broken for years (literally) and nobody complained. If the extensions are removed because of broken code, i can understand, especially for the extensions which have duplicitous functionality which can be obtained by using other X11 features, i do not ask for time to expended to get broken code working. But, if the extensions are in working order, there is no reason or justification to remove them, even if their functionality is duplicated, different applications may be tied to a certain API. We dont like how it looks is not a good reason to remove extensions. Xprint, was this actually broken code, for instance. Ximage, was this broken code? XEVIE, again, was that broken code. What are you referring to by Ximage ? If the extension is broken code, dont waste your time, Im not asking you to spend time on it, we will do our best here to move off of them. But, if the extension is in working order, why not put it back in? To justify removing an extension, the extension needs to be in a broken, non working order, and that it is causing technical problems for the rest of the X system, and to require extensive reworking, and apps can implement what it needs in another way. We dont like how it looks, or we dont think people use this, are not good justifications. Since X.org officially has had all of these extensions until very recently, apparently although they may have been in a non working state, at the same time, they were not causing a problem, so I cannot see the action as being justified to remove them. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
David Gerard wrote: On 1 March 2010 01:28, Richard Brown rbrown1...@gmail.com wrote: Russell Shaw wrote: What are you referring to by Ximage ? Ximage extension to the X server. It has been superceded by MIT shared memory. However, some ancient apps may still use it. It's not clear that *anyone* ever manage to use it successfully. http://en.wikipedia.org/wiki/X_Image_Extension Interesting http://web.archive.org/web/20080413140042/http://people.freedesktop.org/~jg/roadmap.html#mozTocId778727 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Dual-head config broke with update to 1.4.2
Martin Cracauer wrote: ... Anyway... I will also spend some time this week to test the available Window managers to see where they stand wrt xrandr and report back. I noticed that fvwm2 seems broken enough to not even get keyboard focus over to the added desktops, ever. I also don't plan to go devhead GNOME or something like that. E17 I will build if anybody please tells me it is more xrandr aware than E16. I want to make sure that people understand that if there is a WM available that does xrandr with virtual desktops, has a purely file based configuration option and doesn't miss too much functionality I need I will happily switch to xrandr. It's not that I don't stand in front of a projector every now and then and curse that I have to start a second X11 server and can't move my clients between the two. On my todo list is to make a window manager where any application can be set to be mapped only in a specific area of a screen. This is so i can simulate dual-screen operation on a laptop screen. It will be a while before i get around to it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
David Bronaugh wrote: Russell Shaw wrote: *SNIP* You have plenty of time on your hands, don't you? This can mean only one thing: You have an idea to sell, in the hopes that people will jump on board and run with it and you won't have to do any work. I hate to disappoint you, but it doesn't work that way. Ha, no work you say? I need no one elses work, nor do i need to sell anything. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Remote X
Hi, Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? With a unicode text widget, every time a character is entered, the line or paragraph(s) need to be moved and/or reshaped. This can mean sending a few largish bitmaps for every key press. Other toolkits may add new polygon tesselated glyphs to the XRender cache: http://www.keithp.com/~keithp/talks/usenix2001/ http://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt With a cursive font, all the cursive glyphs on a line could compress when the line is close to full, but before the need for a linebreak. That would stress out the cache advantage of XRender. Another problem with XRender is that it's computationally expensive for small systems without polygon hardware. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
Patrick O'Donnell wrote: Date: Wed, 03 Feb 2010 01:18:01 +1100 From: Russell Shaw rjs...@netspace.net.au User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) Sender: xorg-boun...@lists.freedesktop.org Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? I sure hope it is. I typically run X clients on a variety of machines close and far. It's one of the reasons I like (and depend on) X. At the moment I have windows open on six different machines: the local workstation, one on a LAN, four over a VPN to a data center. Three of the latter display at least in part by transferring pixmap data. Network round-trip latency to the data center is about 20-23 ms at the moment. Ok. I will keep it as a priority. Other widget toolkits can be pretty slow over networks i have found. I've wondered if they even bother thinking about performance over networks. ___ 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: X11 fullscreen
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 of C++ toolkit code compared to the results achieved. I find C++ harder to understand and debug compared to C. Gdb had problems with C++. GObject was unsufficiently documented to achieve a full working knowledge of what it is doing. I might be able to figure that out now, but i still find the rest of gtk too tedious to use in C
Re: X11 fullscreen
Daniel Stone wrote: On Thu, Jan 28, 2010 at 10:41:04PM +1100, Russell Shaw wrote: 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. You should read up on Xlib and OpenGL programming. This may not be quick or easy, depending on background, but is worth it if you have ongoing use for it. If you ignore any advice this year, please make it this. And your point is? Too hard? ;) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Alan Cox wrote: One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. And how is your Gujerati and accessibility ... ? Non-existant, but the precise place and how it should be plugged in is defined for easy addition if required. I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. A lot of queries you can avoid the overhead because you can batch queries and answers. You can also stall one thread on a query while others do things. You might be waiting for one window to expose but that doesn't mean you can't be querying other stuff or rendering into other windows at the same time. I need to read the protocol book and understand it properly this time. I have found that even with XSyncronize enabled for worst possible protocol performance, a decent architecture is unaffected. With existing widget toolkits, you're floating that high in the clouds you have no chance of knowing what's happening down below in Xlib and so can't write anything efficiently. One doesn't need to be confined to Xlib drawing functions either. Just bit bang to Shm XImages. Is Xlib thread re-entrant? If not, i may do something about that. Outside of dinosaur land someone already did - its called xcb. I've used that on multiple occaisions and have found simple and required features missing. I have tried adding the missing things by adding new XML definitions. Anyway, i distinctly dislike XML anywhere i would be likely trying to make an improvement to a codebase. xcb is designed to preserve the Xlib api. I prefer to architect things completely new and efficient. If xcb running under Xlib already allows Xlib to be re-entrant, i need not worry. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: Glynn Clements wrote: Russell Shaw wrote: 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. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. 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. 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. 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. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. 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. 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? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Rémi Cardona wrote: Le 29/01/2010 00:41, Russell Shaw a écrit : What i really meant was Forget existing widget toolkits. One can write their own that is much better than the existing ones, if you architect the thing right. Doing that is not a small job. Takes a lot of time just to think about before even writing any code. Right, so let me sum up. Dirk wants to write a full-screen app, with very little interaction with other windows. This is a trivial task for _any_ modern toolkit (gtk, qt, efl, sdl, hell even motif or swing, etc). Your suggestion to Dirk is for him to completely _ignore_ the current toolkits and to start all over from scratch, dropping 10~15 years worth of common knowledge from all the current X-based toolkits. Dirk, please try using one of the current toolkits first. And if you don't like one, try another one, don't write Xlib code directly. That's the toolkit guys' problem, it shouldn't be yours. One challenge: make cairo or gtk drawing full-screen run fast on any current system, or else have it tell your app that such-n-such a feature is not going to be accelerated. All i see in linux gui apps is 10 years of stagnation. And no, i will not use C++ for *anything*. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Mikhail Gusarov wrote: Twas brillig at 23:29:43 29.01.2010 UTC+11 when rjs...@netspace.net.au did gyre and gimble: RS xcb is designed to preserve the Xlib api. I prefer to architect RS things completely new and efficient. Laughed out loud. Sorry, could not resist it. I read, debug, and maintain code that is worth it. This has never included anything using Xlib. I have never wanted to do anything other than using an existing toolkit to solve engineering problems. I'm not even a programmer (tho i seem to be one now). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Nicolas Mailhot wrote: Le Ven 29 janvier 2010 14:40, Russell Shaw a écrit : The right way is to make each font a smart font that is simply a C library plugin. In other words, you can't handle real-world fonts. Since those cost millions and can take months or even years to create (see stix), since people like to have many of them, and want to interoperate with other people that use fonts in existing formats on other systems, I can't see how your advice is anything other than utterly wrong and dangerous. Unless someone has a few billions to blow to check if your idea is workable. It's not a good solution for immediate use, but i only design things the way they should be. Many fonts may cost a bit to make, and sold at extortionistic prices over and over like any other high priced closed source licence software. They also have eulas saying no reverse engineering and no copying. I see any use of truetype/postscript fonts of questionable legality when one has to make a hinting interpreter. Many of these font files are so full of old cruft making them hard to build, verify, and modify, that i avoid them when possible for my own applications. There is no need for font creation to be expensive. It just requires a bit of artistic styling for the outlines, some simple hinting in the vertical direction (for horizontal text), and some predefined language/script specific libraries for contextual analysis. It can all be done as a C plugin making all the interpreter machinery unneccessary. There's no shortage of poor arts students that would create font outlines and have their name on it. With a decent fontforge-like font CAD program and a well defined procedure for creating a font, things would be a lot easier. I'm ok at drawing cursive font outlines on paper anyway. I'll make my own cursive font. Currently i just use font outline data copied from an existing free font for personal use. If such a new font format were released, permission from existing font authors could be sought to copy the outline data. None of this really matters because i don't care if i'm the only one that uses this stuff. I'd prefer to be ignored as a troll because I have a better job than programming all day and just hack on it as a hobby for my own use. Would have been good to see existing software a bit better though. I'm now productive so i'm happy. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
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 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. You should read up on Xlib and OpenGL programming. This may not be quick or easy, depending on background, but is worth it if you have ongoing use for it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Alan Cox wrote: 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. Unless you need to get any real work done - like non western font rendering, accessibility (to make your app meet legal requirements in parts of the world etc) One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. Is Xlib thread re-entrant? If not, i may do something about that. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Glynn Clements wrote: Russell Shaw wrote: 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. On the contrary, using bare Xlib you would be hard pressed to write even a trivial application within a month unless you're willing to give up a lot of features which many people would take for granted (e.g. configuration, support for multiple locales, interoperability with other applications, etc). As with many things, being different is automatically a loss, so you have to do better on the other aspects just to break even. One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Alan Cox wrote: 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. Unless you need to get any real work done - like non western font rendering, accessibility (to make your app meet legal requirements in parts of the world etc) One can do all that with their own libraries based on Xlib. I don't use any Xlib font functions. I'm also not sure why you'd want to use Xlib nowdays. I mean Xlib has a serial non-threaded model without callbacks that causes apps to block on queries - problems you won't have if you hand code the X11 message parser yourself in optimised assembler ;) No way to avoid it. You can't draw on a window until you've waited for the first expose event etc. One doesn't need to be confined to Xlib drawing functions either. Just bit bang to Shm XImages. Is Xlib thread re-entrant? If not, i may do something about that. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I18n text input
Glynn Clements wrote: Russell Shaw wrote: For functions XkbLookupKeySym(), XLookupString(), XKeycodeToKeysym(), XKeysymToString etc, how can i tell if the keysym is a graphic printable character like a, or a control character such as Left (XK_Left) ? I need to tell automatically if it's a normal unicode character that can be printed in an entry box for any written language. For languages other than English, keyboard input isn't as simple as one keypress = one character. Many Western languages use dead accents (i.e. pressing an accent key causes the next character to be accented) or compose processing (e.g. Compose,o,/ = ø), and East-Asian languages typically require far more complex input methods. Do these functions return UTF-8 unicode? XLookupString() uses ISO-8859-1. XmbLookupString() and XwcLookupString() return strings in a locale-specific encoding. If X_HAVE_UTF8_STRING is defined, Xutf8LookupString() returns a UTF-8 string. Hi, I vaguely remember seeing Xutf8LookupString() years ago. All three functions require an input context (see XOpenIM() and XCreateIC() for a starting point, but you probably aren't going to work it out from manual pages alone). Unless you're planning on spending the next few months learning how text entry works for languages other than English, I'd recommend using a GUI toolkit rather than trying to do it using bare Xlib. Or at least steal the code from such a toolkit. I understand everything about non-english text entry and processing. When i do: XIM im = XOpenIM(app-display, NULL, NULL, NULL); im is set to a valid XIM rather than NULL. I thought an input method was supposed to be a separate process, but i haven't started one or used one previously. Where is this one coming from? What sort of text entry can i do with it? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
I18n text input
Hi, For functions XkbLookupKeySym(), XLookupString(), XKeycodeToKeysym(), XKeysymToString etc, how can i tell if the keysym is a graphic printable character like a, or a control character such as Left (XK_Left) ? I need to tell automatically if it's a normal unicode character that can be printed in an entry box for any written language. Do these functions return UTF-8 unicode? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Visuals
Hi, When i do xpyinfo, i get 29 visuals the same: visual: visual id:0xdc class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0xdd class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0xde class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits ... visual: visual id:0xf9 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits Why isn't there just one of each type of visual? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Constraining mouse cursor globally in xorg
Alex White wrote: Hi, Not sure if this is the right place for this question, but here goes.. I need to constrain the mouse cursor in xorg, to prevent it reaching an area of screen that is not visible to the user (don't ask). I've noticed that there is support for this within the x server using the ConstrainCursor function. What this function provides is exactly what I need. What's not clear to me is how I can access this function from the application level. (or is it internal only?). None of the pScreen member functions appear to be exposed in the libraries I've searched. Do I need to write a simple xorg module to do this? Any suggestions on how to proceed? How about: http://tronche.com/gui/x/xlib/input/XGrabPointer.html http://tronche.com/gui/x/xlib/input/XWarpPointer.html To make it global could be done in the window manager maybe. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ctrl+alt_bksp
Vandana Vuthoo wrote: Hi, I am having Xserver as v 1.6 on my intel atom board, some how ctrl + alt + bksp doesnot restart my X server, Even setting setxkbmap -option terminate:ctrl-alt-bksp in xorg.conf doesnot help. Please provide you inputs. Underscores? setxkbmap -option terminate:ctrl_alt_bksp ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Logging out
Hi, In /etc/X11/xorg.conf i have: Section ServerFlags # Allow ctrl-alt-backspace Option DontZap false EndSection but ctrl-alt-backspace doesn't work. (Recent xorg server from debian/unstable: Version: 2:1.6.4-2) How do i log out of X so the xdm screen comes up? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Large scale X
Hi, If i have 1000 user accounts on one accounts server and dozens of X apps on another apps server, how can a user start an X app when they don't have an account on the apps server? (no user accounts at all on apps server) I'm thinking of traditional X where the users use dumb X terminals, and xdm gives the log-in screen. Do i need to use nfs, or is there some better way? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XSetWMProperties
Hi, What's the xcb replacement for XSetWMProperties() ? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Qt colormap problem
Hi, When i run Qt gui apps on a recent X debian/unstable system, when the mouse cursor passes over a Qt window, the whole screen goes black with traces of some menu text still visible, and various widget colours of the Qt app go black too. I don't know if all Qt apps do this. The one that currently does is Skype for Etch: http://www.skype.com/intl/en/download/skype/linux/choose/ http://www.skype.com/go/getskype-linux-deb I'm using the icewm window manager. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Qt colormap problem
Hi, When i run Qt gui apps on a recent X debian/unstable system, when the mouse cursor passes over a Qt window, the whole screen goes black with traces of some menu text still visible, and various widget colours of the Qt app go black too. I don't know if all Qt apps do this. The one that currently does is Skype for Etch: http://www.skype.com/intl/en/download/skype/linux/choose/ http://www.skype.com/go/getskype-linux-deb I'm using the icewm window manager. The colours don't change if the mouse passes over only the titlebar or borders of the window. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Up arrow key not working
Robin Cook wrote: I am using evdev. Section InputDevice Identifier Keyboard0 Driver kbd Option XkbModel evdev Option XkbLayout us Option XkbVariant dvorak Option XkbRules Xorg EndSection gnome keyboard config also shows evdev. and I do have xkeyboard-config is at version 1.4 My arrow key works ok with: Option XkbModel pc104 If i use: Option XkbModel evdev the arrow keys don't work. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Russell Shaw wrote: Peter Hutterer wrote: On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote: I built X from git. I get a stippled background when X starts but the mouse cursor is invisible. The mouse is working because i tested it with xev. I built and installed in this order: commit e02f864fdf19a5ab1682336be343c57fdb69ef43 Author: Adam Jackson [EMAIL PROTECTED] Date: Wed Aug 20 13:24:03 2008 -0400 Suppress cursor display until the first XDefineCursor() request. Yes, this means the server will start without showing a cursor. Pretty much any application that wants to interact with the mouse will define cursors, so this essentially just delays showing it until gdm (or whatever) loads. Hi, That's somewhat interesting. A lot of old or simple X programs (and X tutorials) didn't call XDefineCursor() from what i've seen. When i ran xev (from git), the cursor didn't appear either. I'm testing X on a remote pc and so don't need xdm or any apps running on X. Any testing is simpler if the complications of xdm or a window manager are avoided. I think it would be a good idea if there was a default cursor present if nothing else. I realized that without a window manager you get an ugly black cross cursor which isn't real useful. X should've had a default arrow cursor. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Keith Packard wrote: On Fri, 2008-09-19 at 13:52 -0400, Adam Jackson wrote: You don't ask for the stipple though. It's the default. My point was that if you want to avoid the vintage X appearance, you'd likely start the X server with a black root window instead of the ugly stipple, and we could hook the 'disable the cursor' mode to the same option. Does that seem like a reasonable combination? I just can't imagine any credible desktop environment wanting either the stipple or the X cursor. The protocol, by the way, does _not_ mandate the stipple. It says that the initial contents are some unspecified two-color pattern made of blackPixel and whitePixel. There is a weasel argument here that having zero white pixels still counts as two color I guess. Even if you don't like that argument, we are the keepers of the spec, there's no reason we can't relax that requirement. Yes, I'm cool with the black root background; nicer looking, conforming to the spec and everything. A good solution would be to just replace the black cross cursor bitmap with an arrow cursor that is visible by default. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Peter Hutterer wrote: On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote: I built X from git. I get a stippled background when X starts but the mouse cursor is invisible. The mouse is working because i tested it with xev. I built and installed in this order: commit e02f864fdf19a5ab1682336be343c57fdb69ef43 Author: Adam Jackson [EMAIL PROTECTED] Date: Wed Aug 20 13:24:03 2008 -0400 Suppress cursor display until the first XDefineCursor() request. Yes, this means the server will start without showing a cursor. Pretty much any application that wants to interact with the mouse will define cursors, so this essentially just delays showing it until gdm (or whatever) loads. Hi, That's somewhat interesting. A lot of old or simple X programs (and X tutorials) didn't call XDefineCursor() from what i've seen. When i ran xev (from git), the cursor didn't appear either. I'm testing X on a remote pc and so don't need xdm or any apps running on X. Any testing is simpler if the complications of xdm or a window manager are avoided. I think it would be a good idea if there was a default cursor present if nothing else. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
