Re: Corrupted XImage retrieved from a Window area
On Sun, 31 Jul 2016 07:51:08 + Fabien Lelaquais said: > Thanks a lot for your answer. > Unfortunately I may not be able to rely of the Composite extension (app would > be deployed in environments I don't control). > > Regarding the XGetImage documentation, that I've read ten times: > My drawable (mainWindow) is indeed a viewable window. > It has no inferior, and an overlapping window on its center. The specified > rectangle that I provide, which is the center part of the source window, is > both fully visible on the screen and wholly contained in mainWindow. I have > no X error. And that's why I'm calling for help. you won't get an x error unless the region ends up being out of screen bounds. if pixels of a window are clipped by the screen, a parent window, a shape rectangle list, or are covered by another window... they "do not exist" by default in x11. that is how it works. that is why thomas suggested pixmap redirection to ensure that pixels DO exist and force them to live in a pixmap irrespective of windows overlapping or the window being offscreen. without this you are in regular old x11 mode and if your source is a window... if at the time you grab, you cannot SEE the pixels on a screen... they do not exist. irrespective of if someone drew to them just before. you can never get them. you can "deal with it" and get pixels by setting includeinferiors in your gc subwindowmode before you grab. this will ignore clipping of overlapping windows and just grab whatever is there in the framebuffer as long as your resulting rectangle at the time x performs the grab is still within screen limits. this will get you the content including overlapping window content. this is effectively how you do screenshots in x11. if the region is within screen limits of course... if it is not - problems. if you are managed by a window manager there is always then a race condition where the wm may have moved you off screen but you have not seen the event yet. you can xgrabserver first, then get geometry of your window and translate relative to root to ensure you have the correct clipping coordinates, getimage, then xungrab server to work around the race (and please at least xflush or xsync after the xungrabserver. note. i'm totally ignoring multiple visuals and depths here. :) if your screen consists of lots of windows with differing visuals and depths life gets complex. xv also creates problems if it is using overlays and colorkeys. :) > Thanks again, > > Cheers, > Fabien > > -Original Message- > From: Thomas Lübking [mailto:thomas.luebk...@gmx.de] > Sent: samedi 30 juillet 2016 16:03 > To: Fabien Lelaquais > Cc: x...@freedesktop.org > Subject: Re: Corrupted XImage retrieved from a Window area > > On Sat, Jul 30, 2016 at 08:34:20AM +, Fabien Lelaquais wrote: > >Hi all, > >I'm trying to create an XImage that represents a rectangular portion of a > >Window (because I need to be able to access the actual pixel values). My > >experimentations show that if the source window has an hidden region > >(overlapping window) and if the origin of the rectangle I query is not (0, > >0), then the data is corrupted, resulting in pixels set to 0 in the image > >data (and a black area in the XImage). > > > >I use a raw XGetImage. > > You want to use XCompositeRedirectWindow. This redirects the window into a > pixmap. (What compositors like xcompmgr do) > > > From man XGetImage: > --- > If the drawable is a window, the window must be viewable, and it must be the > case that if there were no inferiors or overlapping windows, the specified > rectangle of the window would be fully visible on the screen and wholly > contained within the outside edges of the window, or a BadMatch error results. > > Cheers, > Thomas > ___ > 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: PutImage vs BackgroundPixmap (was Re: Open Shared Memory and Render Pictures)
On Sat, 06 Aug 2016 13:54:22 +0200 Michael Titke said: > With SHM pixmaps VSI/GIO can finally display a pixmap. While the Intel > graphics card of my old MacBook might not be that speed daemon I'm a > little bit surprised to see "jumpy" window resizes. Perceived > performance is important and sometimes just plainly misleading but both > ShmPutImage (with expose event round trips) as well as a background > pixmap (with deselected expose events and without any round trip) lead > to the same perceived performance where the window border takes its time > to follow the pointer and starts to jump to reach it faster. > The "jumpiness" reminds me of mutex saturation effects or maybe this is > due to the compositing of some part of the Ubuntu Unity Desktop shell > collection? The complexities of the modern input output graph ... no. this is just how it goes. because everything is async, the compositor/wm has resized the window, then some small time later the client gets a configurenotify event, then client renders some update, then sends to x, then x tells compositor of a new damage, compositor gets event goes "ooh time to draw", compositor draws, talks to x again to display... all the while there is no concept of ownership of the window contents. it can change at any time (99.999% of the time changed by the client that created the window) and compositor could be drawing and that content change under its feet while it draws. this is how the cookie crumbles. :) without a compositor - just draop the compositor part of the pipeline - then its still client direct to x and xserver puts it in the framebuffer. there is still async/lag and thus... you will see it. unless of course your system is so insanely fast and workload so low that you can get this done before even a refresh begins on the screen to show the issue. :) > On 05/08/2016 18:58, Dennis Clarke wrote: > > On 08/05/2016 12:38 PM, Ilya Anfimov wrote: > >> X Window Sys- > >> tem Protocol X Consortium Standard. > > > > For those that want to know : > > > > X Window System Protocol X Consortium Standard. > > https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.pdf > > > > ___ > > 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: PutImage vs BackgroundPixmap (was Re: Open Shared Memory and Render Pictures)
On Sat, 6 Aug 2016 15:57:23 +0200 Thomas Lübking said: > On Sat, Aug 06, 2016 at 09:03:04PM +0900, Carsten Haitzler wrote: > > >no. this is just how it goes. because everything is async, the compositor/wm > >has resized the window, then some small time later the client gets a > >configurenotify event, then client renders some update, then sends to x, > >then x tells compositor of a new damage, compositor gets event goes "ooh > >time to draw", compositor draws, talks to x again to display... > > Though the dealbreaker is usually just the clients re-layouting, maybe > sometimes broken XSYNC implementations. > Less the roundtrip itself (which tends to be << 16ms ;-) xsync? you are assuming clients even do an xsync protocol with wm to sync things. there is still a race condition here as wm resizes window first, and client some time later responds with a redraw. xsync really has a limited scope for improvement here. > The solution to this is usually lazy updates by allowing for internal scaling > or padding (if your client has significant payload here) - or anything > else to make the client resize faster. even then frame from wm and client content aren't going to match. :) also one of the big issues here is pixmap re-allocation if composited. this can actually be rather slow on some drivers with continual resizing and it can drop framerate down to 10fps etc. even in your xterm example below. > @Michael, try resizing xterm. If that's slow, there's a problem in the > mechanism. If not, it's just the client. > > Cheers, > Thomas > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: PutImage vs BackgroundPixmap (was Re: Open Shared Memory and Render Pictures)
On Sun, 07 Aug 2016 20:26:37 +0200 Michael Titke
said:
>
>
> On 07/08/2016 18:02, Thomas Lübking wrote:
> > On Sat, Aug 06, 2016 at 05:18:43PM +0200, Michael Titke wrote:
> >> 16 ms ? Usually a hollywood frame needs to be done within 40 ms
> > But your screen refreshes at snappy 60Hz and not some choppy 24fps :-)
> > To be more serious, we clamped resizing to 30fps in kwin (for clients
> > which didn't support the XSYNC protocol) to lower the load on the
> > client. Reason was that no human being can reasonably control sizes at
> > that speed anyway and it's still "smooth enough".
> >
> >> Maybe those old WindowMaker routines from the nineties with the one
> >> pixel bitblt inverse frame ... ;-)
> >
> > Still supported by some WMs. Pace is naturally unbeatable.
> >
> >> Actually the terminal emulators seem to perform better visually: they
> >> only resize when the resize would add or remove a
> >> row or column from the matrix.
> After another review that was only XTerm to perform well: some Gnome
xterm does about the least amount of work. it relies on x background painting
(where x will fill in the default bg for you) so you will have your bg pretty
much correct all the way to window bounds on a resize. it's just the text then
that gets a repaint. this would be the test of the driver pixmap realloc path -
is the driver slow at creating new pixmaps for the compositor? there is
essentially almost nothing to render. the others use different polices and ways
of filling in window content.
> Terminal repaints with white during the overloaded window resizes and
> konsole prefers to show you the composited frame shadows and the
> background of the last resizes for a glimpse.
>
> >
> > That's for the baseincrement size hint. Every client can make use of
> > that but it's oc. very reasonable for clients which display rows and
> > comlums of chars.
> >
> >> frequency events will exhibit some sort flickering effect especially
> >> because the window in the frame buffer / on screen is erased by the
> >> drawing routine of the client when the server already
> >> did that for the expose event.
> >
> > BackingStore, SaveUnder and/or compositors eleminate that problem.
> >
> >
> My preliminary solution was the background pixmap of what was drawn
> where the backing store needs to be readjusted to the actual window
> size. That would have been another great opportunity to run into the
> shared memory segment limit and see the desktop come to a halt. Thanks
you ran into a limit? sure. it exists... but i have NEVER hit it in 20+ years.
and i've used x11-shm extn for as long or longer. i even have shm caches that
leave a bunch of segments around for a bit to recycle them as long as frames
are being pumped out regularly (but i don't actually force a full window-sized
shm seg unless the update region *IS* the entire window, thus the smaller
segments to cover update regions and a pool to pull them out of). actually
thanks to a small bug as a result of moving the shm puts off into a thread,
the shm segs were not getting flushed/cleared but would hang about for a long
time as only new allocations would clear out old unused segments beyond the
cache limit (per process limit was 20m). so even then i never hit a limit.
> to cgroup terminating the session is enough to get a working desktop
> back but the list of shared segments of my mischiefed stress test
> remained in the system data structures and that rebooting attitude ...
oh that's an easy fix.
for I in `ipcs -m | grep 0x | grep $USER | awk '{print $2;}' | awk -F r '{print
$1;}'`; do echo -n "Del SHM: $I ";ipcrm shm $I; done
:) just do that every now and again if you have problem children :)
> That's then the render extension, inter client communication protocol
> and xsync as the next extensions to implement. Thank you for the
> property and xsync hints!
>
> ___
> 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
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
___
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: PutImage vs BackgroundPixmap (was Re: Open Shared Memory and Render Pictures)
On Sun, 7 Aug 2016 17:43:43 +0200 Thomas Lübking said: > On Sun, Aug 07, 2016 at 06:45:29PM +0900, Carsten Haitzler wrote: > >things. there is still a race condition here as wm resizes window first, and > >client some time later responds with a redraw. > > And sometimes never :-) > But visually, this isn't true. Either the compositor can paint last or > (and that's probably more relevant) you configure the window w/o > actually resizing the frame and only resize the frame when the client > ACKs the change. This is basically what allowed us to remove gaps > between the decoration and (supporting) clients. > The pointer will easily go interim off-position, though. this pointer != size can be super annoying. also from the wm/compositor side dealing with "bad clients" that sometimes don't ack or take forever to ack can leave your window "still resizing and waiting for client" and you end up throwing in timeouts for poorly behaving clients. > >actually be rather slow on some drivers > *cough* nvidia *cough*. It's not that bad anymore, though. > > For KWin I had played with lazy configurations (covered by texture > scales in the compositor rather than in the client) - prone to cause > some sea-sickness, though ;-) yeah. tried that too. that was just too horrible to even contemplate shipping at all. my god was it bad with EVERY client and its content. > Cheers, > Thomas > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: Multiplexing general windows similar to terminator
On Sun, 13 Nov 2016 14:27:26 + (UTC) Mihai Darius said: > Hi, > I was thinking about creating a module that allows users to unite graphical > windows in one window, similar to terminator. The end result should look be > similar to how Microsoft Visual Studio manages its windows (e.g. Solution > Explorer, Output, Code, etc.). I am not sure whether anything similar already > exists (I've been searching on Google, but I've found only terminal > multiplexers), and if the implementation should be an X-server module.Any > feedback and help would be greatly appreciated (especially a starting point > for the implementation). Darius Mihai read up on building a window manager. :) you take the blue pill, story ends. you wake up in your bed and avoid the hell that is window management, and believe whatever you want to believe. you take the red pill, you stay in window manager land, and i show you how deep the rabbit hole goes. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: Question about X on the arm's.
On Mon, 21 Nov 2016 17:41:45 -0500 Gene Heskett said: > Greetings X experts; > > I bought a monitor that should have been able to do 1920x1080p60Hz. > One would expect thats a given when the card gets $140 lighter carrying > it out past the RF stuff in Wallies front door frame, so I just bought 2 > of the faster SBC's like the r-pi 3b but the one that will display what > the r-pi 3b puts out, claimed to be a bit faster. > > It wasn't until I googled for its specs last night and discovered its max > is 1366x768 that I actually got a picture out of it hooked to anything > except the r-pi. > > My question has to do with the rendering and screen refresh rate, which > is obviously about 1/4 of the speed an old single core, x86 P4. actually... the pi3 is not that bad. at least when you get to throw all 4 cores around for things like compiling, it's about 50% faster than a 1.5ghz baytrail e3815. at least in my testing that's what the numbers say. also be aware that the x11 code path is actually not that well optimized. where under x11 i'm going to never exceed 30fps doing compositing of my desktop with the gpu, when in wayland mode (exact same WM/desktop config etc.) can manage 60fps... oh and all at 1920x1080p. well dragging my terminals around etc. it's smooth. that may be partly due to being able to do partial updates sensibly supported (haven't checked in egl+x11), or simply due to it being zero copy swaps vs copies in x11. > I am assuming the X built for it is single threaded, and it could be made > more pleasant to use if it scattered its jobs about the 4 cores in the > typical arm cpu. unless you are finding that the xserver process is pegged at 100% cpu... this isn't going to help you at all. reality is that work is split between multiple processes. at least when compositing you will have at LEAST: 1. xorg server 2. wm/compositor 3. client app all churning away and doing things. that would mean that you can at least soak up 3 cpu cores there just by design without magic "lets multithread this formerly single threaded design" work. client apps may use cpu or gpu to render. the compositor likewise may use cpu or gpu. xserver almost definitely is using cpu to do rendering if it is doing any rendering at all. you likely will find that just getting more cores involved doesn't necessarily help. you may be memory bandwidth limited so a single core hammering away on simple memcpy's wont be sped up by 21 or 3 or 4 cores doing the same thing. if anything it slows down as there is more bus contention and possibly cacheline prefetching is hurt by more scattered access patterns. so before looking for some magic "solve my problems by threading" option... profile what is going on as you may actually find this isn't your problem at all... :) > Is there a build switch that could accomplish this? This is a quad core > 64 bit arm cpu, running at its default clock of 1.5GHz which it seems > like should have the ponies to handle the load. More heat sink maybe. > > Is there anything I can do, considering its only other job is serviceing > the keyboard and rodent? > > Thanks everybody. > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > ___ > 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: Question about X on the arm's.
On Mon, 28 Nov 2016 08:49:03 -0500 Gene Heskett said: > On Monday 28 November 2016 07:31:07 Thomas Lübking wrote: > > > On Sun, Nov 27, 2016 at 07:29:14PM -0500, Gene Heskett wrote: > > >Okay anyone, I've had 3 or 4 folks over the last 36 hours claim that > > > X is its own forwarding agent, why am I even using ssh? saying I'm > > > not needing ssh at all. > > > > pass it "-listen tcp", it should open a connection on port 6000+n > > (where n is the server, starting with 0) and you can "export > > DISPLAY=remotedomain:0.0" to run X11 clients on that server. > > > > Notice that this is no good idea unless on a local, friendly network. > > It is, I am the only user, and its all behind dd-wrt, which has not been > penetrated in over a decade. If it wasn't for the need of a switch that > allows these machines access to the net for updates and such, this > particular cable could be 10" long. But since there is a gigabit switch > on the other side of the room, the cat6's will be 50' each by the time > they are fastened down with romex staples. > > The source SBC, an R-Pi 3b which is running an up to date raspian (debian > Jessie built for arm) is running LinuxCNC, which is commanding a 1500 lb > 11x36 Sheldon lathe about 65 yo, will be feeding the display data to a > odroid64, which is claimed to be able to drive a 4k display with a 60 Hz > refresh rate. But when doing so over the ssh xforwarding encrypted > path, is so slow the screen refresh is about 3x a second. Very > distracting, and potentially dangerous when the machine can move 2 or 3 > inches in that time frame. Changing ssh to a faster protocol only got > it up to 5 or 6 frames. I need to get that flicker rate up to a less > distracting rate, something above 20 Hz if possible. The raspi looks at > the machine and takes corrective action every millisecond but it hasn't > got the memory to do the x at the same time. The odroid64 has 2x the > memory and more gpu's and if I can get the data to it, ought to be ble > to do it in real time. > > > Also, all caveats with "modern" toolkits apply here the same (they > > tend to be dead slow over tcp because of the massive image putting, > > you'll only get indirect GL etcetc.) > > > > Cheers, > > Thomas > > > We will see, if I can make it work. I was told I was supposed to just > remove the '-nolisten tcp' from its launch of > exec /usr/bin/X "$@" > in xinit/xserverrc, and that would enable it, no one else has said to > just remove the "no". > > What would be the nmap line to show that it is indeed listening? > > Thank you Thomas. > ssh adds a lot of overhead as it has to decrypt/encrypt, etc. as well as then pass on protocol. depending on the client you are using this could mean a LOT of data having to go through this pipe. clients can easily saturate a 100mbit network. even a gigabit network. it depends on how they work. if you have your xserver listening as normal, it'll be listening on port 6000 if it's display 0 (locally DISPLAY=:0 or DISPLAY=:0.0). 6001 for :1, 6002 for :2 etc. as well. to connect to that display from another machine simply: export DISPLAY=machinename:0 or replace machinename with ip address like: export DISPLAY=192.168.0.2:0 now run whatever x app. note you will ALSO need authorization. the SIMPLEST way is to disable authentication. locally wherever x is running as the person who has authority to connect just do: xhost + you'll have disabled all auth checking for all hosts. read manual page for xhost for more info. you may also want to read the manual page for xauth. your connection either way will not be secure. it can be hijacked or listened to (man int he middle etc.) so as long as you trust your network you're ok, but in general this is a bad idea. be aware that while this will drop the overhead of ssh, your network itself still is a bottleneck. performance can be pretty bad even on gigabit. it all depends on the workload your clients use. since a lot of clients have moved rendering client-side either in software where they just shuffle blobs of pixels to x, or they use opengl with direct rendering and a gpu to do the heavy lifting... the first will eat up bandwidth like there is no tomorrow, and the second will mean clients can't run at all as direct rendering requires you be on the same machine with your client and gpu as the x server, indirect (glx indirect) does exist... but it has been pretty much deprecated and no one tries to really use it anymore for performance reasons... -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: Question about X on the arm's.
On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett said: > On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote: > > > On 11/27/16 04:29 PM, Gene Heskett wrote: > > > Okay Alan, I've had 3 or 4 folks over the last 36 hours claim that X > > > is its own forwarding agent, why am I even using ssh? saying I'm not > > > needing ssh at all. > > > > X can connect directly, but without the encryption & compression that > > ssh adds when it acts as the forwarding agent. ssh has been the > > modern recommended solution for years - all major distros have started > > X with "-nolisten tcp" for over a decade, and recent versions of Xorg > > made that the default, such that you need to go specify "-listen tcp" > > to enable the old direct TCP connection method now if you want to > > avoid ssh. > > > > > So, where can I find the definitive tut on doing this because our > > > attempts are failing? What I was able to find on the xorg web pages > > > last night was up to 3 major versions out of date. I need a tut > > > that deals with X11R7 and up. Is there such a thing? My google-fu > > > is failing me. > > > > Our recommendation for X11R7 remote connections is "Use SSH X11 > > Forwarding." > > > Which works but at very lethargic speeds. 3, 4 frames a second. I need > 20 or more. This odroid64, with at least 3 gpu's is said to be able to > do a 4k display at 60 frames a second. that'd be simply display REFRESH. not actual rendering of content. and forget REMOTE display over ssh over a bottleneck of a network device. forget trying to get anything like high performance over a network connection when it comes to display. don't even bother. it's a waste of time. if it displays at ALL - be happy. to provide updated pixels at 60hz for a 4k display would require a 16 GIGABIT network... with NO OTHER TRAFFIC on it at all. and no network packet/protocol overhead. so let's make that 20 gigabit. that's assuming xputimage with 24bpp images (padded out to 32bpp as that's how xputimage works). that does not account for bottlenecks outside the network itself (the system at either end and it's tpc/ip stack, kernel, memcpy's etc. etc.). > > Unfortunately, so few people are willing to help write X11 docs that > > there isn't a whole lot of stuff written since the X Consortium > > stopped paying doc writers in the mid 90's. > > Yikes! NDW I cannot find uptodate docs & tuts. > > Thanks Alan, I appreciate the candor. > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > ___ > 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: Question about X on the arm's.
On Tue, 29 Nov 2016 09:43:54 +0700 Antoine Martin said: > On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett said: > > > >> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote: > >> > >>> On 11/27/16 04:29 PM, Gene Heskett wrote: > >>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim that X > >>>> is its own forwarding agent, why am I even using ssh? saying I'm not > >>>> needing ssh at all. > >>> > >>> X can connect directly, but without the encryption & compression that > >>> ssh adds when it acts as the forwarding agent. ssh has been the > >>> modern recommended solution for years - all major distros have started > >>> X with "-nolisten tcp" for over a decade, and recent versions of Xorg > >>> made that the default, such that you need to go specify "-listen tcp" > >>> to enable the old direct TCP connection method now if you want to > >>> avoid ssh. > >>> > >>>> So, where can I find the definitive tut on doing this because our > >>>> attempts are failing? What I was able to find on the xorg web pages > >>>> last night was up to 3 major versions out of date. I need a tut > >>>> that deals with X11R7 and up. Is there such a thing? My google-fu > >>>> is failing me. > >>> > >>> Our recommendation for X11R7 remote connections is "Use SSH X11 > >>> Forwarding." > >>> > >> Which works but at very lethargic speeds. 3, 4 frames a second. I need > >> 20 or more. This odroid64, with at least 3 gpu's is said to be able to > >> do a 4k display at 60 frames a second. > > > > that'd be simply display REFRESH. not actual rendering of content. and > > forget REMOTE display over ssh over a bottleneck of a network device. > > forget trying to get anything like high performance over a network > > connection when it comes to display. don't even bother. it's a waste of > > time. > I beg to differ. An arm CPU certainly makes this more of a challenge, > but it is not a lost cause... just don't use SSH forwarding, some tuning > IS required. it has nothing to do with an arm cpu... it's the network. see below. if someone is quoting "this arm SoC can do UHD at 60hz" then you're in fantasy land thinking you can even get anywhere NEAR that. even 1080p at 20hz would need 1.3 gigabit of pure bandwidth on the network without any protocol etc. overhead. so let's round that up to 1.5 gigabit allowing for overhead and other misc traffic. you'd have to keep that bandwidth fed solidly ANd also copy data to the framebuffer etc. > > if it displays at ALL - be > > happy. to provide updated pixels at 60hz for a 4k display would require a > > 16 GIGABIT network... with NO OTHER TRAFFIC on it at all. and no network > > packet/protocol overhead. so let's make that 20 gigabit. that's assuming > > xputimage with 24bpp images (padded out to 32bpp as that's how xputimage > > works). that does not account for bottlenecks outside the network itself > > (the system at either end and it's tpc/ip stack, kernel, memcpy's etc. > > etc.). > I don't think the OP is trying to watch a 4K video over TCP, rather > stating that his hardware is capable of pushing 4k@60 pixels, which is > why he was expecting better results. see above. 1080p @ 20hz would exceed any network adaptor he has. i don't know what this odroid64 is, but if he;s talking of the odroid's from hardkernel, then the TOP of the line they have is the xu4 (or xu3 - not available anymore but identical to the xu4 simply with more usb ports, more display ports etc.). the xu3 has a gigabit port. let's get to some reality... i have an xu3. i also have a pc. both with gigabit ethernet ports attached to a gigabit switcch. guess what? the BEST you can get without any overhead (simple ftp) is about 11-12Mb/sec ... ftp reports: 746748440 bytes sent in 63.9 seconds (11.1 Mbytes/s) when transferring this EATS kernel space cpu. ftpd is consuming 74% cpu and its almost all kernel space (system) cpu. that's JUST to transfer a file directly to disk. it'll be doing it all to ram cache so it isn't i/o limited by emmc as the xu3 has 2Gb of ram. so without any encryption overhead the network can at best do let's say 12Mb/sec. at just 1080p 24bpp (padded to 32bpp) that's 1.5 fps. 1.5. that's all his device will do. that is of course assuming generating new pixel data every frame (client side rendering). sur
Re: Question about X on the arm's.
On Tue, 29 Nov 2016 10:58:37 +0700 Antoine Martin said: > On 29/11/16 10:28, Carsten Haitzler (The Rasterman) wrote: > > On Tue, 29 Nov 2016 09:43:54 +0700 Antoine Martin > > said: > > > >> On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote: > >>> On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett > >>> said: > >>> > >>>> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote: > >>>> > >>>>> On 11/27/16 04:29 PM, Gene Heskett wrote: > >>>>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim that X > >>>>>> is its own forwarding agent, why am I even using ssh? saying I'm not > >>>>>> needing ssh at all. > >>>>> > >>>>> X can connect directly, but without the encryption & compression that > >>>>> ssh adds when it acts as the forwarding agent. ssh has been the > >>>>> modern recommended solution for years - all major distros have started > >>>>> X with "-nolisten tcp" for over a decade, and recent versions of Xorg > >>>>> made that the default, such that you need to go specify "-listen tcp" > >>>>> to enable the old direct TCP connection method now if you want to > >>>>> avoid ssh. > >>>>> > >>>>>> So, where can I find the definitive tut on doing this because our > >>>>>> attempts are failing? What I was able to find on the xorg web pages > >>>>>> last night was up to 3 major versions out of date. I need a tut > >>>>>> that deals with X11R7 and up. Is there such a thing? My google-fu > >>>>>> is failing me. > >>>>> > >>>>> Our recommendation for X11R7 remote connections is "Use SSH X11 > >>>>> Forwarding." > >>>>> > >>>> Which works but at very lethargic speeds. 3, 4 frames a second. I need > >>>> 20 or more. This odroid64, with at least 3 gpu's is said to be able to > >>>> do a 4k display at 60 frames a second. > >>> > >>> that'd be simply display REFRESH. not actual rendering of content. and > >>> forget REMOTE display over ssh over a bottleneck of a network device. > >>> forget trying to get anything like high performance over a network > >>> connection when it comes to display. don't even bother. it's a waste of > >>> time. > >> I beg to differ. An arm CPU certainly makes this more of a challenge, > >> but it is not a lost cause... just don't use SSH forwarding, some tuning > >> IS required. > > > > it has nothing to do with an arm cpu... it's the network. see below. if > > someone is quoting "this arm SoC can do UHD at 60hz" then you're in fantasy > > land thinking you can even get anywhere NEAR that. even 1080p at 20hz would > > need 1.3 gigabit of pure bandwidth on the network without any protocol etc. > > overhead. so let's round that up to 1.5 gigabit allowing for overhead and > > other misc traffic. you'd have to keep that bandwidth fed solidly ANd also > > copy data to the framebuffer etc. > > > >>> if it displays at ALL - be > >>> happy. to provide updated pixels at 60hz for a 4k display would require a > >>> 16 GIGABIT network... with NO OTHER TRAFFIC on it at all. and no network > >>> packet/protocol overhead. so let's make that 20 gigabit. that's assuming > >>> xputimage with 24bpp images (padded out to 32bpp as that's how xputimage > >>> works). that does not account for bottlenecks outside the network itself > >>> (the system at either end and it's tpc/ip stack, kernel, memcpy's etc. > >>> etc.). > >> I don't think the OP is trying to watch a 4K video over TCP, rather > >> stating that his hardware is capable of pushing 4k@60 pixels, which is > >> why he was expecting better results. > > > > see above. 1080p @ 20hz would exceed any network adaptor he has. i don't > > know what this odroid64 is, but if he;s talking of the odroid's from > > hardkernel, then the TOP of the line they have is the xu4 (or xu3 - not > > available anymore but identical to the xu4 simply with more usb ports, more > > display ports etc.). the xu3 has a gigabit port. let's get to some > > reality... > > > > i have an xu3. i also have a pc. both with gigabit ethern
Re: Question about X on the arm's.
On Tue, 29 Nov 2016 01:04:23 -0500 Gene Heskett said: > On Monday 28 November 2016 22:58:37 Antoine Martin wrote: > > > On 29/11/16 10:28, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 29 Nov 2016 09:43:54 +0700 Antoine Martin > said: > > >> On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote: > > >>> On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett > said: > > >>>> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote: > > >>>>> On 11/27/16 04:29 PM, Gene Heskett wrote: > > >>>>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim > > >>>>>> that X is its own forwarding agent, why am I even using ssh? > > >>>>>> saying I'm not needing ssh at all. > > >>>>> > > >>>>> X can connect directly, but without the encryption & compression > > >>>>> that ssh adds when it acts as the forwarding agent. ssh has > > >>>>> been the modern recommended solution for years - all major > > >>>>> distros have started X with "-nolisten tcp" for over a decade, > > >>>>> and recent versions of Xorg made that the default, such that you > > >>>>> need to go specify "-listen tcp" to enable the old direct TCP > > >>>>> connection method now if you want to avoid ssh. > > >>>>> > > >>>>>> So, where can I find the definitive tut on doing this because > > >>>>>> our attempts are failing? What I was able to find on the xorg > > >>>>>> web pages last night was up to 3 major versions out of date. I > > >>>>>> need a tut that deals with X11R7 and up. Is there such a > > >>>>>> thing? My google-fu is failing me. > > >>>>> > > >>>>> Our recommendation for X11R7 remote connections is "Use SSH X11 > > >>>>> Forwarding." > > >>>> > > >>>> Which works but at very lethargic speeds. 3, 4 frames a second. > > >>>> I need 20 or more. This odroid64, with at least 3 gpu's is said > > >>>> to be able to do a 4k display at 60 frames a second. > > >>> > > >>> that'd be simply display REFRESH. not actual rendering of content. > > >>> and forget REMOTE display over ssh over a bottleneck of a network > > >>> device. forget trying to get anything like high performance over a > > >>> network connection when it comes to display. don't even bother. > > >>> it's a waste of time. > > >> > > >> I beg to differ. An arm CPU certainly makes this more of a > > >> challenge, but it is not a lost cause... just don't use SSH > > >> forwarding, some tuning IS required. > > > > > > it has nothing to do with an arm cpu... it's the network. see below. > > > if someone is quoting "this arm SoC can do UHD at 60hz" then you're > > > in fantasy land thinking you can even get anywhere NEAR that. even > > > 1080p at 20hz would need 1.3 gigabit of pure bandwidth on the > > > network without any protocol etc. overhead. so let's round that up > > > to 1.5 gigabit allowing for overhead and other misc traffic. you'd > > > have to keep that bandwidth fed solidly ANd also copy data to the > > > framebuffer etc. > > > > > >>> if it displays at ALL - be > > >>> happy. to provide updated pixels at 60hz for a 4k display would > > >>> require a 16 GIGABIT network... with NO OTHER TRAFFIC on it at > > >>> all. and no network packet/protocol overhead. so let's make that > > >>> 20 gigabit. that's assuming xputimage with 24bpp images (padded > > >>> out to 32bpp as that's how xputimage works). that does not account > > >>> for bottlenecks outside the network itself (the system at either > > >>> end and it's tpc/ip stack, kernel, memcpy's etc. etc.). > > >> > > >> I don't think the OP is trying to watch a 4K video over TCP, rather > > >> stating that his hardware is capable of pushing 4k@60 pixels, which > > >> is why he was expecting better results. > > > > > > see above. 1080p @ 20hz would exceed any network adaptor he has. i > > > don't know what this odroid64 is, but if he;s talking of the > > > o
Re: Question about X on the arm's.
On Mon, 28 Nov 2016 23:40:45 -0800 Alan Coopersmith said: > On 11/28/16 07:58 PM, Antoine Martin wrote: > > Even 100mbit is perfectly usable for remote access provided you use the > > right tools and make some sacrifices. FYI: 4K@60 "fits" in H264 ~60Mbps. > > But again, as I said above, just don't expect to handle fullscreen video > > on arm where *we* don't support hardware H264 decoding. (though other > > tools might) > > But we're talking the X11 protocol, not H264. X11 doesn't compress video > at all - you need an external proxy to do that, and since LBX support was > dropped from the X server years ago, that leaves ssh X forwarding with > compression, or picking an alternate protocol such as VNC or RDP. or raw good old x11 protocol without ssh fwding. my numbers above aren't for video encoding but for transfer of pixel data (xputimage) which is pretty common in how apps work these days unless it's opengl that they use. you'd need ridiculous bandwidth just to SCROLL a fullscreen image around eg in gimp or to zoom it in and out. you'll be getting like a few fps on a good day 1-3fps). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: help with Xorg (Adam Jackson)
On Mon, 31 Jul 2017 17:21:08 -0500 "Perez Rodriguez, Humberto I" said: > Hi Adam : > > > with '-retro' option now i can a gray background and the cursor, but i > am not able to do anything else, could you point me in how to do in > order to run some X clients against my X server please ? switch to another VT (ctl+alt+f2 or whatever) then log in, and export DISPLAY=:0 xterm i am assuming the xserver is coming up as the default :0 one. also assuming you have xterm installed. > On 7/31/2017 12:43 PM, Adam Jackson wrote: > > On Mon, 2017-07-31 at 12:15 -0500, Perez Rodriguez, Humberto I wrote: > >> Hi Adam : > >> > >> there is the full log > > This log appears to show a successful startup. You say you only see a > > blank screen, but a black background with no cursor is in fact the > > default. If you're simply trying to test whether X works, the '-retro' > > command line option will paint the old root weave and X cursor. But > > otherwise X doesn't draw anything on its own, and you will need to > > actually run some X clients against your X server if you want to see > > anything. > > > > - 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: help with Xorg (Adam Jackson)
On Wed, 2 Aug 2017 10:46:30 -0500 "Perez Rodriguez, Humberto I" said: > Thanks, in fact i dont know to much about xorg and your help here > always is welcome :) > > after run it the both commands with the same user i am now able to see > in a little white box the terminal with xterm, but now the big question > is how can i display the windows, wallpapers and everything else like > xorg does by default ? xorg does not display these by default. xorg does NOTHING by default. all of this stuff is done by your login session apps like the window manager and so on. you've gotten past your issue. the xserver works. it worked before (just was black). xorg, its rendering, drivers, input work. you have a terminal. you can type in it. you want to start a whole x SESSION. that's what things like startx, xdm, gdm, kdm, slim, lightdm, etc. etc. etc. do - they do all of this and go launch everything (and in the case of all by startx also handle logging in a specific user and authenticating them if needed). this is what all those desktops - enlightenment, gnome, kde, xfce do. they provide all the thing you CALL an xorg desktop. each is its own project. you want to run one of those in your login session. as above - these tools generally would do that for you. they may use your ~/.xsession script to decide what to do or ~/.xinitrc or provide a gui to select a session. you would need something installed. you could install more basic window manages with far less stuff like twm. fvwm, etc. etc. too... but you will want something else than just xorg. xorg is basically a driver with an ipc/network front end that apps talk to to do the rest. > On 8/2/2017 7:41 AM, Thomas Lübking wrote: > > On Tue, Aug 01, 2017 at 02:43:55PM -0500, Perez Rodriguez, Humberto I > > wrote: > >> > >> after try the command below, i get the following error : > >> > >> xterm: Xt error: Cant open display: :0 > >> > >> > >> as a comment, i've tried as well with "export DISPLAY=:[0-6]" without > >> success :( > > > > No offense, but you didn't happen to switch back to the VT from where > > you launched X11 and interrupted that process in order to enter the > > xterm command, did you? > > IOW: Is the X11 server still running on another VT when you tried this? > > ps aux | grep Xorg > > > > Otherwise: Did you run both commands as the same user? > > > > The number behind the colon btw. does not refer to the VT. > > > > Cheers, > > Thomas > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: help with Xorg (Adam Jackson)
On Tue, 1 Aug 2017 14:43:55 -0500 "Perez Rodriguez, Humberto I" said: for now use -ac when you run Xorg by hand. Xord -ac :0 or whatever. > > after try the command below, i get the following error : > > xterm: Xt error: Cant open display: :0 > > > as a comment, i've tried as well with "export DISPLAY=:[0-6]" without > success :( > > > On 7/31/2017 6:35 PM, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 31 Jul 2017 17:21:08 -0500 "Perez Rodriguez, Humberto I" > > said: > > > >> Hi Adam : > >> > >> > >> with '-retro' option now i can a gray background and the cursor, but i > >> am not able to do anything else, could you point me in how to do in > >> order to run some X clients against my X server please ? > > switch to another VT (ctl+alt+f2 or whatever) then log in, and > > > > export DISPLAY=:0 > > xterm > > > > i am assuming the xserver is coming up as the default :0 one. also assuming > > you have xterm installed. > > > >> On 7/31/2017 12:43 PM, Adam Jackson wrote: > >>> On Mon, 2017-07-31 at 12:15 -0500, Perez Rodriguez, Humberto I wrote: > >>>> Hi Adam : > >>>> > >>>> there is the full log > >>> This log appears to show a successful startup. You say you only see a > >>> blank screen, but a black background with no cursor is in fact the > >>> default. If you're simply trying to test whether X works, the '-retro' > >>> command line option will paint the old root weave and X cursor. But > >>> otherwise X doesn't draw anything on its own, and you will need to > >>> actually run some X clients against your X server if you want to see > >>> anything. > >>> > >>> - 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 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ 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: clone window try2
On Thu, 14 Jun 2018 19:00:07 +0200 be ba said: what you want could be done by a compositor or compositing window manager. in x a window has only one geometry (size and position) and one place in the window tree. that is not going to change. if you just wanted a "show multiple copies of the window" but don't want to interact with all copies (click with mouse etc.), then a compositing wm could easily do this just by drawing the same window in multiple locations, since compositors "composite" the screen and do the rendering/display rather than the xserver itself. enlightenment does just this with it's pager for example (the pager for virtual desktops shows a miniature of each desktop with all windows with content live and updated in miniature). enlightenment is just making duplicate views of the same windows in the pagers. it does the same for the task switcher/launcher/dock in the menu and so on). so it is possible: 1 wm already does it all day long. enlightenment doesn't have the exact feature you are asking for here, but the infra is there to easily add it window by window, desktop by desktop etc. but back to xmonad, you'd need a compositing wm and i believe xmonad is not. a separate compositor wouldn't work well as this would require integration to know what virtual desktop os active, know when they change, which windows are in each desktop and appropriately arrange window content and/or rendering correctly (to make this work the wm can't unmap windows to switch desktops. to keep the content from another desktop's windows still updating you do tricks like not unmapping but just moving out of the way (via stacking or shape extension input regions etc. to remove the input areas), and just stop drawing those windows if they are not visible on the current desktop. xmonad won't be doing that i would say as it's not a compositing wm. so ... you either need to switch wm's, or make xmonad a compositing wm. you should talk with the maintainers/authors of xmonad first to see if such patches would ever be accepted before you begin, otherwise you will be taking on forking of the project, so be prepared for that. > Hi, > > I think my first email got lost, because I didn't receive a copy from > the mailing list: > > I am using the tiling window manager xmonad [1] and two physical > monitors with different size. In xmonad you have 9 workspaces by default > and it allows you to have two of the workspaces to be seen at the the > physical monitors. For doing a presentaion with a projector it would be > beneficial to have one workspace to be shown at both physical monitors > so you can see what the audience is seeing. Currently xmonad does not > support this. > > So theoretically I could use the xrandr tool to achieve that. I was able > to get it working and it worked quit well. However I want this cloning > behavior to be triggered by xmonad itself. Theoretically xmoand could > dynamically apply xrandr commands and temporally move these CRTC things > around the screen. However this does not seem to be a desirable > approach. [2] > > I came this fare to find out that xmoand uses XMoveResizeWindow() to > place the window on the screen. However with XMoveResizeWindow() you can > only provide one coordinate for the position at a time. So I would need > something where I can submit a list of x and y's and the window gets > cloned at the various places. Unfortunately I have not found anything > like that. > > So my question is: What would be the correct approach for my > undertaking/What features are appropriate for this and do they actually > exist/(And does my idea actually make sense)? > > thanks for any help, > Be > > > [1] https://github.com/xmonad/xmonad > [2] I think xmonad should not manipulate what was configured by xrandr. > One good reason for that appears to me that with xrandr you tell X how > your pyhiscal devices are located on you desk. And then it is intuitive > how you mouse appears and dissapears while you move around. Also your > windows can float around between multiple monitors and different parts > of the window appearing on diffrent monitors don't get shuffeled around. > When the CRTC things get moved around the courser might get cloned as > well as well as the floating windows. I would not consider this correct > behavior for xmonad. > > ___ > 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 -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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: XDrawPoint(s) etc MT safe?
On Tue, 16 Oct 2018 22:04:15 -0400 Dennis Clarke said: > On 10/16/2018 09:58 PM, Dennis Clarke wrote: > > > > Dear Xorg : > > > > Something I had not thought of came up today. Could multiple threads > > call XDrawPoint() and then XFlush() ? Suppose sixteen threads are > > dispatched to do some foo and each of them utters some XDrawPoint() > > calls and then XFlush()? Is that remotely thread safe? > > > > Sorry, assume XInitThreads() is in place. Am I stuck with using > XLockDisplay() and XUnlockDisplay() and really multiple threads can > not really do work simultaneously. That is the question. xinitthreads should make anything in xlib "mt safe".. but only in as much as doing the calls will not mess up xlib state or the socket/protocol pipeline. (note that if this does happen it'd be an xlib/xcb bug). but ... how can you sensibly have 2 threads draw to the same target in any way ... unless you very specifically avoid ever overdrawing on the same areas (e.g. use 4 threads and split region into a 2x2 grid of target areas to draw into), or you always draw the same color points so that it doesn't matter which gets drawn first etc. ... ? xflush will flush whatever is queued in the xlib buffer irrespective of which thread put it there... :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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: Questions on pointer barrier behaviour
On Tue, 10 Sep 2019 21:49:51 +0200 Michael Weiser said: > Hello, > > I've written a small X client that detects when the pointer hits a > screen edge in order to trigger actions based on where the edge was hit > - the classic hot corner use case. The trigger for doing this yet again > was that all the tools I looked at either polled the pointer position or > subscribed to all pointer motion which irked me on an aesthetic level. ;) you know the ancient trick is just to place input only windows along all the screen edges and listen for mouse enter/leave events... :) (override-redirect ones). catch - wm's do this too (enlightenment does) so you may fight with the wm's own windows on these screen edges... :) so 1 pixel wide or high window ... for 4 windows along the edges of each screen. :) requires no extensions to so this. the won't suffer any of your below issues as the cor pointer will always be trapped/stopped ad a screen boundary :) > I've now placed non-constraining pointer barriers at all screen edges > using Xfixes and get notified through XInput2 when the pointer hits them > which seems very efficient to me and works quite well. I've noticed a > couple of things though: > > 1. Since barriers have a 2px hit box[1] I thought I could nicely use the > XI_BarrierHit event to detect that the user had activated a hot corner > or edge and XI_BarrierLeave to learn when the pointer moved away again. > Since I didn't want to risk any interference with normal user experience > and only wanted to get notified anyway I made the barriers > non-constraining. This however meant that I got a leave event for every > hit even though the pointer was pushing at the very edge of the screen > not going anywhere. > > Moving the pointer very slowly it can be seen that first there is a hit > event event for the initial hit but then pushing onwards off-screen > produces a leave as if the pointer actually moved beyond the barrier and > out of the hit box even though continually hitting the screen edge. It > snapping back from off-screen then seems to produce another hit event. > > This can be reproduced by changing the interactive demo[2] to place the > barrier at the very top or bottom of the screen. > > It also happens with a constraining barrier anywhere on the screen when > approaching it along a screen edge (i.e. as if trying to sneak around it > off-screen and being caught :). > > 2. Moving the barrier away from the screen edge to then track its > crossing and somehow devise whether it was an entry or departure I found > that for non-constraining barriers, I'm not reliably getting events for > every crossing of the barrier. Neither pointer speed nor input device > (trackpad, mouse) seem to be a factor - for some crossings I just get no > event. This also happens with the interactive demo[2] after making the > barrier non-constraining and deactivating the release code. > > 3. Making a barrier that starts at a screen edge constraining and then > releasing the pointer immediately after receiving the barrier hit event > shows another peculiar behaviour: When moving the pointer against the > barrier along that screen edge so that it continually tries to push > off-screen makes it get stuck at the barrier *while* barrier hit events > keep coming in and being released. It seems as if the release is getting > lost on the way. This can be reproduced with the interactive demo[2]. > > As said above I've worked around this to my satisfaction but am still > wondering if those behaviours are to be expected or indeed bugs in any > participant of the interaction (my brain being the prime suspect :). > > And finally any advice on whether pointer barriers are a good choice for > the hot corner use case in the first place would be highly welcome. > > [1] https://who-t.blogspot.com/2012/12/whats-new-in-xi-23-pointer-barrier.html > [2] > http://people.freedesktop.org/~whot/xi2-recipes/pointer-barriers-interactive.c > -- > Thanks, > Michael > ___ > 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 -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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 run Xserver without a installed console
On Wed, 8 Jan 2020 15:31:41 +0100 "Mgr. Janusz Chmiel" said: > Good afternoon, > Please, does somebody of you know about The tešchnique, which would allow Me > to run Xserver even if I do not have console app installed? > I want to run startx coomand from Debian, which run on Android by using > Termux and Proot app. Unfortunately, there is no Linux console, so I can not > run xserver by typing startx. > My intention is to use dummi Xorg video driver and I want to run x11vnc app > to interact with running GTK app. > Because Tigervnc app and others do not allow Me to run window managers. Only > if I run X11vnc window managers can correctly detect XKB extension > presented. Use Xvfb as the Xserver instead of regular Xorg? > I have one special xorg.conf configuration file, which should help. But > because Chroot environmentdo not support virtual console, I can not use > xserver by typing startx. > > I guess, that removing some code to bypass this check will not be good ieda. > So why Xorg need to detect if user have Linux console installed? > Because Xorg would not had to display something on physical screen in my > cause. I only need to run x11vnc, which will not work without running Xorg. > I have consulted it with x11vnc developer. And perhaps it would not be > problem, that I will use Xorg dummi video driver instead of physical driver. > Because I do not see at all and I would like to use Mocha VNC from GOogle > Play to control my running app. > Because Xserver XSDL still do not support all X11 protocol extensions. > Thank you for yours advices. > > ___ > 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 > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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: WM_DELETE_WINDOW does not send ClientMessage
On Sun, 19 Jan 2020 15:17:17 +0100 Roland Plüss said:
> Hi Lucien,
>
> Depends what you call the same display. The window is created in the
> render thread while event looping is done in the main thread. In both
> places XOpenDisplay(getenv("DISPLAY")) is called. Is this not the same
> display? If not how can I "attach" them together? It's a requirement
> that the render thread creates the window while the main thread has to
> handle the event loop (to my knowledge only this works).
you use 2 display handles? oh... you're asking for trouble. you're asking
for ownesrship and lifecycle issues there as well as race conditions.
xlib can handle threads on the same Display handle, you just need to
XInitThreads() before you go using more than 1 thread with it. :)
> On 1/19/20 2:43 PM, Lucien Gentis wrote:
> >
> > Hello Roland,
> >
> > While defining delAtom and calling XSetWMProtocls, you specifiy
> > "display", and in your loop, you specify "pDisplay" ; is it the same
> > display ?
> >
> > Le 19/01/2020 à 13:33, Roland Plüss a écrit :
> >> I'm finishing up my software for releasing but run into a big issue. If
> >> I use window mode instead of full-screen mode the user should be able to
> >> close the window using the X button. I can prevent this from happening
> >> using this code:
> >>
> >> Atom delAtom = XInternAtom( display, "WM_DELETE_WINDOW", False );
> >> XSetWMProtocols( display, pWindow, &delAtom, 1 );
> >>
> >> The window will not be destroyed when X is pressed so I think this
> >> worked. The problem is though that I do not received ClientMessage and
> >> thus I am unable to close the window. This is the event loop:
> >>
> >> XEvent event;
> >> while( XPending( pDisplay ) ){
> >> XNextEvent( pDisplay, &event );
> >> log("Event %d", event.type);
> >> switch( event.type ){
> >> ...
> >> case ClientMessage:
> >> log("Quit Request Received");
> >> break;
> >> }
> >> }
> >>
> >> Window is created like this:
> >>
> >> #define BASIC_EVENT_MASK ( StructureNotifyMask | ExposureMask |
> >> PropertyChangeMask \
> >> | EnterWindowMask | LeaveWindowMask |
> >> KeyPressMask \
> >> | KeyReleaseMask | KeymapStateMask |
> >> FocusChangeMask )
> >>
> >> #define NOT_PROPAGATE_MASK ( KeyPressMask | KeyReleaseMask |
> >> ButtonPressMask \
> >> | ButtonReleaseMask | PointerMotionMask |
> >> ButtonMotionMask )
> >>
> >> XSetWindowAttributes swa;
> >> swa.colormap = colMap;
> >> swa.backing_store = NotUseful;
> >> swa.border_pixel = 0;
> >> swa.event_mask = BASIC_EVENT_MASK;
> >> swa.do_not_propagate_mask = NOT_PROPAGATE_MASK;
> >> swa.override_redirect = False;
> >> swa.save_under = False;
> >> swa.cursor = 0;
> >> swa.bit_gravity = ForgetGravity;
> >> swa.win_gravity = NorthWestGravity;
> >>
> >> Any idea what else I need to do to get this working?
> >>
> >>
> >> ___
> >> 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
>
> --
> Mit freundlichen Grüssen
> Plüss Roland
>
> Leader und Head Programmer
> - Game: Epsylon ( http://www.indiedb.com/games/epsylon )
> - Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
> , http://dragengine.rptd.ch/wiki )
> - Sowie verschiedene Blender Export-Skripts und Game-Tools
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
___
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: WM_DELETE_WINDOW does not send ClientMessage
On Sun, 19 Jan 2020 19:05:58 +0100 Roland Plüss said:
> In many cases I can do it purely on the render thread only if this
> helps. If though a toolkit is involved (FOX in this case) then I need to
> "inject" the render window.
>
> I can prevent synchronization issues easily if this is required as I
> have a specific synchronization window so no two display would access X
> at the same time. Would this help?
well you already hit a problem... you had events going to different places.
you'll hit more as time goes on if you use 2 display connections and actively
do different things in each. especially things like create a window in one of
them then listen for events for it in another. you will find wonderful gotchas
like only one of those display connections can get mouse button press/release
events, both can get mouse motion but only until some button is held down... in
this case "first come, the only one served". you will find things like handling
of operation now goes out of order. i hope you set an x error handler rather
than rely on the standard xlib one too... or you're in even deeper trouble etc.
just fair warning. you walk down a dangerous path i wouldn't advise unless you
are an old x hack who has been around the block a few times and knows the
nasties that shall happen... :)
> On 1/19/20 6:28 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 19 Jan 2020 15:17:17 +0100 Roland Plüss said:
> >
> >> Hi Lucien,
> >>
> >> Depends what you call the same display. The window is created in the
> >> render thread while event looping is done in the main thread. In both
> >> places XOpenDisplay(getenv("DISPLAY")) is called. Is this not the same
> >> display? If not how can I "attach" them together? It's a requirement
> >> that the render thread creates the window while the main thread has to
> >> handle the event loop (to my knowledge only this works).
> > you use 2 display handles? oh... you're asking for trouble. you're
> > asking for ownesrship and lifecycle issues there as well as race conditions.
> >
> > xlib can handle threads on the same Display handle, you just need to
> > XInitThreads() before you go using more than 1 thread with it. :)
> >
> >> On 1/19/20 2:43 PM, Lucien Gentis wrote:
> >>> Hello Roland,
> >>>
> >>> While defining delAtom and calling XSetWMProtocls, you specifiy
> >>> "display", and in your loop, you specify "pDisplay" ; is it the same
> >>> display ?
> >>>
> >>> Le 19/01/2020 à 13:33, Roland Plüss a écrit :
> >>>> I'm finishing up my software for releasing but run into a big issue. If
> >>>> I use window mode instead of full-screen mode the user should be able to
> >>>> close the window using the X button. I can prevent this from happening
> >>>> using this code:
> >>>>
> >>>> Atom delAtom = XInternAtom( display, "WM_DELETE_WINDOW", False );
> >>>> XSetWMProtocols( display, pWindow, &delAtom, 1 );
> >>>>
> >>>> The window will not be destroyed when X is pressed so I think this
> >>>> worked. The problem is though that I do not received ClientMessage and
> >>>> thus I am unable to close the window. This is the event loop:
> >>>>
> >>>> XEvent event;
> >>>> while( XPending( pDisplay ) ){
> >>>> XNextEvent( pDisplay, &event );
> >>>> log("Event %d", event.type);
> >>>> switch( event.type ){
> >>>> ...
> >>>> case ClientMessage:
> >>>> log("Quit Request Received");
> >>>> break;
> >>>> }
> >>>> }
> >>>>
> >>>> Window is created like this:
> >>>>
> >>>> #define BASIC_EVENT_MASK ( StructureNotifyMask | ExposureMask |
> >>>> PropertyChangeMask \
> >>>> | EnterWindowMask | LeaveWindowMask |
> >>>> KeyPressMask \
> >>>> | KeyReleaseMask | KeymapStateMask |
> >>>> FocusChangeMask )
> >>>>
> >>>> #define NOT_PROPAGATE_MASK ( KeyPressMask | KeyReleaseMask |
> >>>> ButtonPressMask \
> >>>> | ButtonReleaseMask | PointerMotionMask |
> >>>> ButtonMotionMask )
> >>>>
> >>>> XSetWindowAttributes swa;
> >>>> swa.c
Re: How to start with X?
On Wed, 22 Jan 2020 18:26:32 +0100 Emanuele Petriglia said: > Hi! > > I would like to learn how to create a C graphical application without > using some toolkit for hobby. I know that there are two main libraries: > Xlib and xcb. The first is old but has a lot of documentation, the > second is newer but less documented than the first. So I was thinking to > learn Xlib and then xcb. > > I found this book about Xlib: "XLIB Programming Manual" of Adrian Nye > published on 1994. I do not found any other recent book. Is it good to > start with Xlib even is it old? Advice: stick with Xlib. More examples. More docs. XCB is only better in a few very specific cases that mostly are the areas WM and toolkit authors might obsess over for small gains in performance. So stick to Xlib - that's my advice. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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: Variable DPI according resolution AND screen size
On Sat, 15 Feb 2020 00:10:22 +0100 Luis Felipe Sánchez-Escobar Retamar said: > Hello all, > > Today we have a lot of differents screens, in both aspects size and > resolution. > And a fixed DPI of 96 has no sense. This is absolutely not true and has not been for a very long time (a fixed DPI). Sure - for the old x multi-screen (not xrandr) setup and api each SCREEN had its own DPI. You used to have multiple root windows and screen with each their own DPI. If you still used X in this way you'd have different DPIs per screen. Xrandr/xinerama merged all screen into a single screen/root window negating that design in return for convenience, and xrandr then exposed the DPI for different regions of the same root window to account for that. > I think that could be a good thing to do an automatic adjustment of DPI > with the algorithm like in http://dpi.lv/ > Implemented directly in X > > And not depends on how each desktop environment manage DPI X already exposes the DPI of each and every screen via xrandr. It has done its job. X is about mechanism, not policy (primarily - debates in corners rage). The policy is then is implemented by desktops/WMs and whatever other tooling a user chooses. As an aside, I'll actually disagree with your link. It's not DPI or PPI. It's PPD. Pixels Per Degree of visual field. A 20m high monitor/projection at the other end of a large room has very very very low DPI, but this is irrelevant to the person sitting at the back of the room far away, whereas a phone held up very close to your eyes is different to a tablet, laptop, desktop etc. due to distance between eyes and screen. What matters is how many pixels per degree. So in then end this is all just a continuation of the "we're emulating paper and a computer is a device to drive a printer as final output" model when we've already moved beyond it in various ways. In the end the only thing that makes sense is a "this is too big/small - make it smaller/bigger" slider and users set it up because that also then accounts for people with 20/20 or better vision or those who need a lot of visual helpers (glasses etc.) and have poor eyesight. For large rooms with large audiences spread through them then you have to make a call for "worst case" (people in the back) and go for that. You also can use xrandr's scale/transform options to have X force scaling at the output level (comes with upsides and downsides - definitely downsides in performance, but upsides in simplicity for apps and consistent physical surface sizing if used right). So in the end you leave it to higher level software to figure it out because that's the only way to solve this with consistence AND performance AND TV on the other side of living room vs projector at other end of presentation hall vs monitor vs. phone etc. use cases. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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: X server does not have an option to specify which address to listen on for TCP connections
On Mon, 11 May 2020 14:38:48 + ornx said: > ‐‐‐ Original Message ‐‐‐ > On Monday, May 11, 2020 8:18 AM, Attila Kinali wrote: > > > On Mon, 11 May 2020 01:41:11 + > > ornx o...@protonmail.com wrote: > > > > > why? > > > > Probably because it has never come up? X was intended to be used > > on desktops, which, usually, had only a single network interface. > > In case restrictions were needed, xauth/xhost provided the means > > to limit access. These days TCP is even disabled on most distros > > by default, for security reasons. > > > > Attila Kinali > > >X was intended to be used on desktops > is this really true? my understanding is that X has always had a networked > client/server model This has not been true for a long time. X has become highly local. This has been covered in many blogs, conference presentations etc. over the years. You are quoting a design ethos from the 80's and maybe 90's that has long since died since then. :) > my use case is that i need X to use TCP so that i can intercept its traffic > with wireshark for debugging purposes, but i only need this server accessible use xscope instead probably. It understands x protocol... :) > on the loopback interface and specifically do not want it listening on any > other interfaces for basic security reasons of not giving programs any > network resources that they do not strictly need. using xauth/xhost seems > insufficient for this purpose, because i already know that i do not want any > external traffic to be able to access the server, why do i need to decide > this at the application level instead of specifying it at the network level? > what if there is a bug in the X authentication mechanism? the workaround for > this is also rather inconvenient and requires specialized knowledge, to > prevent external network traffic from reaching X now involves writing > firewall rules instead of merely setting a flag limiting the interfaces that > X is listening on. it is also at odds with normal networking application > behavior, i have actually never encountered a program before that listened on > a port but did not allow to specify the listening interface > > is the reason why this behavior has not been implemented in Xorg simply > because nobody has thought to add it, or is there a specific reason that it > was left out? if someone provided a patch implementing this behavior, would > it have a chance of being merged? > ___ 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 -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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: AW: Implementing PseudoColor support on TrueColor screens
On Tue, 2 Jun 2020 10:06:01 + Walter Harms said:
> the correct way to do is use XPutPixel().
Unfortunately it's also the very slow way. The right way is to handle the pixel
data pointer yourself correctly given format (8, 16, 32bit) and x visual rgb
masks and use the bytes_per_line correctly. This is your fast path for all
the common cases. Also try implement them in SIMD (MMX/SSE/Nneon/SVE/Altivec
etc.). If it's not an optimized common path, then fall back to XPutPixel.
You probably want to have the palette lookup table specifically filled and
optimized for the pixel format "ahead of time" so it's already 1:1 correct for
the right xRGB pixel value to expand to so all you need is a dumb lookup,
so the expand code is something like:
// assume the following input:
//unsigned char *srcpixel; // is input pointer top-left to bottom right
//int w, h; // size of image in pixels (width and height)
//unsigned int palette_lookup[256]; // expanded index -> xRGB 32bit layout
// // you could do the same for 16bpp too
unsigned char *pixelrow;
unsigned int *pixel;
pixelrow = (unsigned char *)ximage->data;
// work from top left to bottom-right row by row
for (y = 0; y < h; y++) {
pixelrow += ximage->bytes_per_line;
pixel = (unsigned int *)pixelrow;
for (x = 0; x < w; x++) {
pixel = palette_lookup[*srcpixel];
pixel++;
srcpixel++;
}
}
Even better if you can throw some SIMD in (I'd need to think about it a bit,
so not going to do it in an e-mail) and then write out 2 or 4 pixels at a time
(you then jump by 4 pixels at a time, instead of 1, dealing with
non-multiple-of-2-or-4 sizes as a special end-of-row cleanup at the end of a
row).
Also you really should use XShmPutImage - it's drastically faster than basic
XImage (but only for local xservers, so you have to query for it and test you
can XShmAttach() - will not work across a network). Also keep in mind that you
can have several XShmPutImages in flight as it's async, so look for the xshm
completion event to know when to clean up or be able to recycle your shm
segment - just keep a pool of xshm images/sysv shm segments around and as puts
complete put them back in the spare pool and when you need a new shm image for
a new frame, look in your pool for an available image, or create it if needed
then). You could also be lazy and use XSync()... :) it comes with blocking as a
side-effect.
> color these days if pretty easy color=0/r/g/b
>
> You need a lookuptable for 256 colors (=st2d_8to24table[i] ?)
> and that should it be.
>
> re,
> wh
>
>
> Von: xorg im Auftrag von Sleep
> Gesendet: Dienstag, 2. Juni 2020 08:28:13
> An: xorg@lists.x.org
> Betreff: Implementing PseudoColor support on TrueColor screens
>
> Is there any documentation, article or book on how to convert the colors
> displayed by a program that was originally written to work on 8 bit
> screens? The problem I am facing seems to be related to how pixels are
> represented in the 'data' member of the XImage structure, which results
> in a squashed image and colors being displayed incorrectly. The only
> reference I have are two functions in the Quake source code:
> xlib_rgb24()[1] and st3_fixup()[2], which are used to convert the colors
> (but I cannot comprehend them because the format is unknown to me), but
> I found nothing that could make the image fill the window[3] properly. I
> could use SDL to easily get around this issue but I specifically want to
> use Xlib.
>
> I appreciate any help to learn.
>
> [1]
>
> [2]
>
> [3] https://postimg.cc/MfRz0Dk7
> [4] https://i.postimg.cc/brVdhC3B/doom.png
> ___
> 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
>
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
___
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, 23 Jul 2020 04:19:16 -0400 Elie Goldman Smith said: this has nothing to do with xorg - each toolkit and/or client app implements this. xorg/xlibs just provide the mechanisms. they all do this because in x it *IS* expected behaviour and has been expected to work this way for 30 years or so... your rationale applies equally to ctrl+v ... it can also be accidentally pressed. imagine a heavy terminal user hits ctrl+c to "Stop that" and focus is on the wrong window... your rationale then would apply to this situation too, so this should also be disabled. your logic leads to the following conlusion: all pastes need to be disabled by default probably with a "you want to paste 'xyz' ... are you sure [yes] [no]" approval dialogs... :) you are definitely welcome to suggest this to toolkit and app makers. :) > X.Org, to whom it may concern: > > I'm writing to suggest that Xorg's middle-mouse pasting should be an > optional feature, not an unchangeable behavior. > > The rationale is simple: > Middle-mouse pasting is only beneficial to users who know that it exists. > For everyone else, it's a liability. > > Say for example a user is writing a document, scrolling through it, > and accidentally pastes text without knowing it. > The pasted text might contain sensitive/private information. > The user submits the document somewhere, and people read it. > It's more likely than you think. > > This isn't simply a matter of mouse scroll wheels that click too > easily. Laptop touchpads are known to paste accidentally too. Even > 2-button emulation is a liability, if the user doesn't remember to > deliberately avoid pressing both buttons at once. > > > 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. > > > Thanks > - Elie > > > P.S. > Current workarounds involve either: > - completely disabling the middle mouse button > - blocking the feature in specific apps only > - scripts that continuously delete Xorg's clipboard every half-second > > We can do better. > > P.P.S. > I would bet that desktop linux distros would disable middle-mouse > pasting by default, if they could. > Many users are new to Linux, and are used to absent-mindedly clicking > the scroll wheel while scrolling. > Hardcore coders can always re-enable the feature via 'xset'. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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, 30 Jul 2020 14:39:04 -0400 Elie Goldman Smith said: > Countless people on forums say that middle-mouse pasting is an X11 feature. > > This document seems to confirm that it's an X11 feature: > https://www.jwz.org/doc/x-cut-and-paste.html > > > Please correct me if I'm wrong. It's an ecosystem convention. It's not a feature of xorg or the xorg core libraries (xlib) specifically (though xt/xaw does implement it but almost no one uses that anymore so it's moot). These tools are used to implement middle-mouse past by toolkits. They all then repeat the pattern making it an ecosystem-wide convention. Not just toolkits but entire apps that don't use toolkits at all implement it too. I'd advise that just because a lot of people say something, does not make it true. When you talk to developers here who know and write the actual code that is involved in this and they tell you otherwise, you'd be wise to take that as actual fact. You are welcome to dig into all of the code yourself and prove them wrong... I'm sure they are all cracking open a beer and waiting with baited breath to see the results. :) > 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 > > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ 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
