Re: The keyboard interfaces and protocols in X
I should preface by saying that I reverse-engineered this, based on time-consuming searches, and by picking up some clues in xorg's source. This was a long time ago, I don't remember where I found everything, I forgot, and only have the end results. This is what I have: https://github.com/svarshavchik/libcxxw/blob/master/keysyms.C You need the keycode and the current input mask. keysym_lookup() produces both a unicode character and a keysym. Note that this deals with keyboard events only. Other kinds of X interactions will introduce you to wonderful compound_text encoding. That's going to be its own slice of heaven. On Mon, Feb 14, 2022 at 4:58 AM Andrew Bainbridge wrote: > > I tried to do something similar and had the same experience. I still don't > know how to convert keyboard events to something useful like UTF-8. (I was > actually aiming for Latin-1 to start with). > > My terrible code is here: > https://github.com/abainbridge/deadfrog-lib/blob/master/src/df_window_x11.cpp > > The keycode conversions are done in x11KeycodeToDfKeycode() and > dfKeycodeToAscii(). > > If someone would like to tell me (and John) how to do better, that'd be > great, as long as it doesn't involve adding any dependencies to my code :-) > > - Andy > > On Sun, Feb 13, 2022, at 5:01 PM, John Found wrote: > > Hi. > > I am trying to create a X client that to communicate to X server by the > raw protocol, not using any libraries, such as XLib or XCB. > > While with the graphics part it was simple and straightforward task, > solved by simply following the protocol (The documentation on X11 is > pretty complete and well written) and extensions documentation is > available (although the MIT-SHM documentation on the protocol does not > exists at all), I have stuck with the keyboard part of > the protocol. > > The biggest problem is the conversion from the keycodes into the > Unicode characters (of course where it is possible). > > Do I need XKEYBOARD extension? On only XINPUT. Or both. The > documentation is complex and poorly written. I have a feeling that part > of it was written not to be useful, but simply because it had to be > written. > > So, the question: > > What is the simplest, canonical, expected way to handle the keyboard > events in X protocol in order to obtain the Unicode codes of the > pressed keys? In raw protocol therms. And supporting multiple > languages, of course. > > I understand that some processing on the client side is required, but I > am missing the whole picture of the process. > > Best Regards. > John Found > >
Re: x opacity
On Thu, Jan 6, 2022 at 3:37 AM Paum B. wrote: > > Hi, I don't know where I should ask. > > I want to achieve: vim in terminal, with possibility to put 100% opacity to > everything besides text I am writing, so that all terminal window, except my > text is transparent. You will need to check the settings of whatever terminal program you're using to see how you can set the background color, this is controlled by your terminal program's settings. It is also possible that your terminal program is integrated into your desktop environment, and there's a transparent display theme. In any case this is entirely dependent on whatever terminal and desktop environment you're using, this is not standardized in any way by X.
Re: Beginner Questions About XCB - xcb_alloc_color is too slow
On Sun, Feb 21, 2021 at 4:47 PM Carsten Haitzler wrote: > > Use Xlib. Or just use a toolkit higher up the stack. XCB really is for people > who already know X backwards. It can buy some speedups in some corner-cases by > avoiding round trips to the server and back and putting the job of doing it > async in your hands. Don't start with XCB. It's a great way to drive yourself > insane. Well, I started with XCB. Some might disagree, but I still have all my marbles. Not only have I started with XCB, I learned X11 with XCB. And I rode that horse all the way up to a widget toolkit based on XCB. So, I'm evidence that learning X11 with XCB is doable. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Beginner Questions About XCB - xcb_alloc_color is too slow
On Sat, Feb 20, 2021 at 9:37 PM Mark Solomonik wrote: > > Hello, > I am trying to implement a 3D engine from scratch with XCB. To do this, I > have to set the color of every individual pixel before drawing it. > > I noticed that calling xcb_alloc_color and xcb_alloc_color_reply are > bottlenecking the program and making it slow to draw individual triangles. I made the same mistake a while ago. AllocColor is superceded by the RENDER protocol extension which, if you dig into it, you can find out which bits in a 24 or a 32 bit pixel correspond to the red/green/blue/alpha channels. AllocColor was used in prehistoric times when dinosaurs roamed the earth and VGA hardware was able to handle a maximum of 16, 32, or similar number of colors on screen, so each window registered which handful of colors it wanted to use, and each time you switched windows the X server loaded the window's colors into the hardware registered that corresponded to each possible 4, 5, or similar bits per pixel (and all other windows from other applications changed into weird colors). Those days are long gone. It's safe to assume that modern hardware supports RENDER. The bad news is that, when starting from scratch, it'll take at least three months to pour through RENDER's documentation (that's a very optimistic estimate, it took me much longer than that) before everything soaks into your brain, and you "get it". > Is this an appropriate way to set the color? Is there a more efficient way to > do so? This is as efficient as it gets. Each function call is a round-trip to the X11 server. > Slightly unrelated question: as someone completely new to Xorg and Linux > graphics in general, > how do you deal with the lack of documentation for XCB? There's nothing to document. XCB is just a thin wrapper around the underlying X11 protocol. Which explains why you are unhappy about the performance of AllocColor, you did not realize that what this does is send a request to the X server and wait for the response. You need to find the documentation for whichever parts you want to use. For the core X11 protocol it's https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html You will find a curious pattern of X11 requests specified in this documentation matching one-for-one with the xcb functions you're already using, and their parameters. And then the light bulb over the top of your head goes off. The only thing that XCB really does on its own is the allocation of XIDs, but that's not too difficult to figure out. RENDER is here: https://www.x.org/releases/X11R7.7/doc/renderproto/renderproto.txt The RENDER requests documented there will also match, bit by bit, with the xcb_render* functions in xcb, and so on. Probably the stuff that is the least match is all the setup stuff, which is where you will find all the goodies related to the video hardware and how to decode which bits in a pixel correspond to which channel. But once you find one end of the thread in the header files the rest won't be hard to unravel. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: restart Xorg? | fedora 32 | mem leak?
On Thu, Feb 18, 2021 at 11:48 AM Tom wrote: > > After a week or two Xorg grows -- last time to about 3.6GB. How may I restart > Xorg with out rebooting, or disturbing my current session? > > -- > thanks, > Tom > > -- > systemctl restart display-manager # works, but I have to restart all my > graphical tools The problem here might be due to those same X clients and tools being sloppy. Many years ago I discovered that the input method server was creating a new atom for every new input method client. It never reuses atoms of disconnected clients. Once created, the server keeps these atoms forever, until the server is restarted. That's what X11 specifies. I reported this, but they were not interested in fixing their logic. Most high level widget toolkits implement an interface to the input method server for you. They connect to the IM server when the application starts. Grand total: each X client you start ends up with a new atom getting created. It's unlikely that this would amount to multiple gigabytes, over a course of a week, but every little bit, like that, contributes to the memory footprint of the X server. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Where to check for supported radeon hardware
I am trying to vet some hardware to buy, and make sure that, well, the video card will work. I see many builders offer radeon video cards with model names like rx 550, rx 570, and rx 590. I can't find any mention of these models on https://www.x.org/wiki/RadeonFeature/#decoderringforengineeringvsmarketingnames or anywhere else I poked. Yet, I can find some bug reports, like https://bugs.freedesktop.org/show_bug.cgi?id=106327 that reference it as supported hardware. So, what's the story on Radeon in 2020/2021? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Nouveau lockups
I started getting random X lockups. They happen randomly. Usually during video playback, but sometimes also waking up from sleep, and sometimes when doing something else, no rhyme or reason. The laptop can be ssh-ed into and rebooted, to completely recover. I'm running Fedora, and this started to happen with the 5.8 series kernels, and just happened on 5.9.8, too. The video hardware is "01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [Quadro 1000M] (rev a1) (prog-if 00 [VGA controller])": The following stuff gets dropped into syslog, which I believe is the culprit. Is this a kernel, or an x.org issue? Nov 22 18:44:56 thinkpad kernel: nouveau :01:00.0: fifo: write fault at 0004d08000 engine 15 [PCE0] client 01 [PCOPY0] reason 02 [PAGE_NOT_PRESENT] on channel 1 [007fbb3000 DRM] Nov 22 18:44:56 thinkpad kernel: nouveau :01:00.0: fifo: ce0 engine fault on channel 1, recovering... Nov 22 18:47:56 thinkpad kernel: nouveau :01:00.0: Xorg[1009]: failed to idle channel 3 [Xorg[1009]] Nov 22 18:48:11 thinkpad kernel: nouveau :01:00.0: Xorg[1009]: failed to idle channel 3 [Xorg[1009]] Nov 22 18:48:11 thinkpad kernel: nouveau :01:00.0: fifo: read fault at 013000 engine 07 [PFIFO] client 07 [BAR_READ] reason 02 [PAGE_NOT_PRESENT] on channel 3 [007faf2000 Xorg[1009]] Nov 22 18:48:11 thinkpad kernel: nouveau :01:00.0: fifo: fifo engine fault on channel 3, recovering... ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: poly line issue
On Mon, Nov 9, 2020 at 4:30 PM Per Dalgas Jakobsen wrote: > > Hi, > > I'm trying to learn coding with XCB and found an issue the XCB people > think should be placed her. > Drawing a diamond seems to render correctly only if started (end ended) > at the right-most corner, drawing from any other corner causes the > right-most pixel not to be rendered. libxcb has no involvement with actual drawing or rendering. It's sole function is to transmit requests, and all their parameters, to the X server which then executes them. libxcb is really just a very thin mapping layer between a functional API and X protocol messages. What you want to do is investigate the formal X protocol specification, which defines how various coordinates and parameters get interpreted. > xcb_poly_line (connection, XCB_COORD_MODE_ORIGIN, window, > foreground, 5, diamond); This would be the PolyLine request: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:PolyLine Note the nuanced detail of how various coordinates get interpreted and the meticulous detail in defining the actual drawn pixels. Elsewhere in this specification you will find the formal definition of the low level data points. For example, in general, line drawing-related requests specify the coordinates for the center of the drawn line. A question then arises, if the line's width is given as an even number of pixels, what actual pixels get drawn? If the line's width is given as 1, 3 or 5 pixels, for example, and it's a vertical line, which pixels get drawn is not such a big mystery. But what if it's 2 or 4 pixels, then what? You're going to have to sift through the specification, to get the details of what happens. That's just one example (whose answer I don't recall off the top of my head), you'll have to decipher what's happening in your case similarly. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Suggestion for Xorg / about middle-mouse click pasting
On Fri, Jul 31, 2020 at 4:37 PM Adam Jackson wrote: > > (accidentally sent to just sam initially, whoops) Yes, and just had a two minute look at it -- this just seems to disable pasting of the PRIMARY selection, completely. I suppose that's one way to disable the middle mouse click. As well as the "Paste" option from most applications' "Edit" menu, and/or the equivalent keyboard combination. I suppose that this is one way to fix the problem. > > On Fri, Jul 31, 2020 at 7:22 AM Sam Varshavchik > wrote: > > On Fri, Jul 31, 2020 at 4:30 AM Böszörményi Zoltán wrote: > > > 2020. 07. 30. 21:20 keltezéssel, Dennis Clarke írta: > > > > On 7/30/20 6:39 PM, Elie Goldman Smith wrote: > > > >> Countless people on forums ... > > > > > > > > Also they are not the source code nor would I rely on what countless > > > > people say on just about any matter whatsoever. I am not sure when > > > > the horrific "popular is correct" logic became almost defacto pure > > > > truth but I reject it. I am certain I am not alone but I also do not > > > > have a mathematical proof handy to refute the "popular is correct" > > > > notion. At least not yet. > > > > > > Let me suggest an analogue / convergent notion, which is also popular > > > among engineers: "ten billion flies can't be wrong. let's eat sh*t" > > > I am not sure this refutes the "popular is correct" logic but it > > > certainly puts things into perspective. > > > > That's somewhat besides the point. The point is that the server has > > absolutely no control over this functionality. Anyone who actually > > knows and understands X11 (and not some uncounted number of people in > > some mysterious forums) will know that. > > > > If someone believes otherwise, they are free to download the source to > > the Xorg server, make whatever the change they believe will adjust > > that behavior, and prove everyone else wrong. > > Fine, I'm feeling contrarian: > > https://gitlab.freedesktop.org/snippets/1127 > > The server _absolutely_ has control over this. The value of the > PRIMARY property, from the requesting client's perspective, is > whatever the server says it is. There's no reason the server needs to > tell you the truth. I'm pretty sure you could craft selinux policy to > do this and not even need to patch your server. > > The point is: opinions about this are not universal. PRIMARY's > behaviour is so thoroughly baked into both client software and a > non-trivial subset of user expectation that anyone saying "obviously > it should be turned off" is projecting. Likewise anyone who cut their > teeth on a sun3 and thinks UI design was perfected with the Athena > widget set is intentionally ignoring the absolutely massive > popularization of access to computing since 1992. > > Nobody needs a manifesto about this. If you want to improve the world > here the quantity of code needed is really quite small. I would like > to think the xorg developers are friendly and approachable enough that > people would feel comfortable asking how to make these kinds of > changes and where to start hacking. We've done tremendous amounts of > work over the last 15-odd years to eliminate the irrelevant code and > make what's left pleasant to work on. Please don't make me feel like > that's been wasted effort. > > - ajax > > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: https://lists.x.org/mailman/listinfo/xorg > Your subscription address: %(user_address)s ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Suggestion for Xorg / about middle-mouse click pasting
On Fri, Jul 31, 2020 at 4:30 AM Böszörményi Zoltán wrote: > > 2020. 07. 30. 21:20 keltezéssel, Dennis Clarke írta: > > On 7/30/20 6:39 PM, Elie Goldman Smith wrote: > >> Countless people on forums ... > > > > Also they are not the source code nor would I rely on what countless > > people say on just about any matter whatsoever. I am not sure when > > the horrific "popular is correct" logic became almost defacto pure > > truth but I reject it. I am certain I am not alone but I also do not > > have a mathematical proof handy to refute the "popular is correct" > > notion. At least not yet. > > Let me suggest an analogue / convergent notion, which is also popular > among engineers: "ten billion flies can't be wrong. let's eat sh*t" > I am not sure this refutes the "popular is correct" logic but it > certainly puts things into perspective. That's somewhat besides the point. The point is that the server has absolutely no control over this functionality. Anyone who actually knows and understands X11 (and not some uncounted number of people in some mysterious forums) will know that. If someone believes otherwise, they are free to download the source to the Xorg server, make whatever the change they believe will adjust that behavior, and prove everyone else wrong. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Suggestion for Xorg / about middle-mouse click pasting
On Thu, Jul 30, 2020 at 3:06 PM Elie Goldman Smith wrote: > Countless people on forums say that middle-mouse pasting is an X11 feature. "X11" is not the same thing as an "X server". > This document seems to confirm that it's an X11 feature: > https://www.jwz.org/doc/x-cut-and-paste.html Yes, it does. This document confirms that middle mouse button click events are X11 features. Pay attention to this part: # So how do I implement this? # # middle button paste, if implemented | Retrieve and insert PRIMARY selection. Pay attention to the "if implemented" part. If not implemented, this does nothing. An X client chooses to implement whatever events it wants. If it chooses to implement the middle button as a paste button, it then proceeds to retrieve and insert the PRIMARY selection from the server. If it chooses not to do so, nothing happens. The X server has absolutely nothing to do, whatsoever. The X server's only responsibility is to forward mouse button events to the client, to do whatever it wants with it. If the client chooses to implement the middle button as a paste operation, that's the client's choice. Not the server's. Feel free to read https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html at your leisure, for all the details. > > > Please correct me if I'm wrong. > > > On Friday, July 24, 2020, Alan Coopersmith > wrote: >> >> On 7/23/20 1:19 AM, Elie Goldman Smith wrote: >>> >>> Solution: >>> Middle-mouse pasting would be great as a setting that can be >>> enabled/disabled by 'xset' on the command line. >>> >>> Please let me know if this would be simple to implement. >> >> >> It would not be, because it is not a X server behavior. It is simply >> a convention implemented in dozens of toolkits and thousands of >> applications, with no centralized control. >> >> All the X server does is tell the client that button 2 was pressed, and >> everything after that happens client side. >> >> -- >> -Alan Coopersmith- alan.coopersm...@oracle.com >> Oracle Solaris Engineering - https://blogs.oracle.com/alanc > > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: https://lists.x.org/mailman/listinfo/xorg > Your subscription address: %(user_address)s ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: BadAccess to a GrabButton
On Mon, May 4, 2020 at 3:57 AM Walter Harms wrote: > > Hi Sam Varshavchik, > could you please elaborate a bit what you are doing exactly ? > Someone should be able to replicate that you are doing. > > You have a (simple) programm you can share ? > Even pseudo code would be ok. I'm working on my own X11-based widget library because ...that's what I do in my free time. For that reason, the entire code dump of https://www.libcxx.org/w/ is not likely to work here. I was just hoping anyone would know off the top of their head of any other reason I might get a BadAccess response to a GrabButton, other than the only reason described in the X11 specs. The only reason I could find there was a conflicting grab, but according to x11trace I was ungrabbing the button before grabbing it again. In the meantime, for other reasons I had to reorder some of the event handling in my library, and that made the error disappear. From what I can tell, this sequence of events is identical: 000:<:0533: 24: Request(28): GrabButton owner-events=false(0x00) grab-window=0x0323 event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion pointer-mode=Synchronous(0x00) keyboard-mode=Synchronous(0x00) confine-to=None(0x) cursor=None(0x) button=any button(0x00) modifiers=AnyModifier 000:<:06a7: 24: Request(28): GrabButton owner-events=false(0x00) grab-window=0x0320004d event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion pointer-mode=Synchronous(0x00) keyboard-mode=Synchronous(0x00) confine-to=None(0x) cursor=None(0x) button=any button(0x00) modifiers=AnyModifier 000:<:06d8: 12: Request(29): UngrabButton button=any button(0x00) grab-window=0x0320004d modifiers=AnyModifier 000:<:09f3: 24: Request(28): GrabButton owner-events=false(0x00) grab-window=0x0320004d event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion pointer-mode=Synchronous(0x00) keyboard-mode=Synchronous(0x00) confine-to=None(0x) cursor=None(0x) button=any button(0x00) modifiers=AnyModifier 000:<:0a0a: 12: Request(29): UngrabButton button=any button(0x00) grab-window=0x0320004d modifiers=AnyModifier 000:<:0a0d: 12: Request(29): UngrabButton button=any button(0x00) grab-window=0x0323 modifiers=AnyModifier For grab-window=0x0320004d there's a grab, an ungrab, grab again, and ungrab. Same as last time. Although the other events are different, based on my read of the specs only other grabs should matter here, and nothing else. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
BadAccess to a GrabButton
I'm running automated tests that map/unmap things quickly, amongst other things. I am getting a BadAccess in response to one of the GrabButton requestrs, and I can't figure out why (x11trace): 000:>:0705:Error 10=Access: major=28, minor=0, bad=79691853 X documentation says that BadAccess results from either a conflicting grab from another client or if I already have another passive grab. Grepping x11trace log, these are the only GrabButton and UngrabButton events I see: 000:<:053b: 24: Request(28): GrabButton owner-events=false(0x00) grab-window=0x04c3 event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion pointer-mode=Synchronous(0x00) keyboard-mode=Synchronous(0x00) confine-to=None(0x) cursor=None(0x) button=any button(0x00) modifiers=AnyModifier 000:<:06ae: 24: Request(28): GrabButton owner-events=false(0x00) grab-window=0x04c0004d event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion pointer-mode=Synchronous(0x00) keyboard-mode=Synchronous(0x00) confine-to=None(0x) cursor=None(0x) button=any button(0x00) modifiers=AnyModifier 000:<:06d1: 12: Request(29): UngrabButton button=any button(0x00) grab-window=0x04c0004d modifiers=AnyModifier 000:<:0705: 24: Request(28): GrabButton owner-events=false(0x00) grab-window=0x04c0004d event-mask=ButtonPress,ButtonRelease,EnterWindow,LeaveWindow,PointerMotion pointer-mode=Synchronous(0x00) keyboard-mode=Synchronous(0x00) confine-to=None(0x) cursor=None(0x) button=any button(0x00) modifiers=AnyModifier 000:<:071c: 12: Request(29): UngrabButton button=any button(0x00) grab-window=0x04c0004d modifiers=AnyModifier 000:<:071f: 12: Request(29): UngrabButton button=any button(0x00) grab-window=0x04c3 modifiers=AnyModifier Request 0705 is the one that returned an error. I do not see any conflicts here. I do not get a BadAccess if I add a flush and a sleep, after the grabs, so there must be a race condition somewhere? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: How to change mouse cursor to standard hand cursor
Cosmin Apreutesei writes: You may want to check the documentation for your desktop manager. How can I detect at runtime which desktop manager is running so I can take it from there? Desktop managers typically set their own desktop manager-specific properties in the root window. The typical approach is to have a list of known properties each particular desktop manager, and check if it's set. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
