Re: xorg performance in general / eclipse specific question (2)

[Antoine Martin]

On 28/05/12 23:22, David Aldrich wrote:
>> Although it's hard to tell, but if there is an xserver running on the vmware
>> host then it might be an app which does too much data transfer (like
>> pixmaps), which fine locally, but not over a network
>
> Which xserver would you suggest as a better alternative?
(I am totally biased) but I would suggest using software designed for
forwarding applications over the network rather than a "real" xserver
with vnc: something like Xpra or NX.
http://xpra.org/
http://nomachine.com/

Antoine

>
> David
> ___
> 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: anto...@nagafix.co.uk

___
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: arch...@mail-archive.com

Re: resetting server without loosing clients?

[Antoine Martin]

On 22/02/14 08:41, Glynn Clements wrote:
> Steven Feil wrote:
>
>> Is there a way to reset/restart the Xorg server without killing the
>> programs that are clients of the server? 
> No.
>
>> Or possibily, is
>> there some a way will keep the clients alive (similar to nohup) and
>> allow me to reattach them to the server once it is restarted?
> You could use VNC, i.e. have the clients connect to Xvnc and have the
> real X server run the VNC viewer (in full-screen mode) as its sole
> client.
Or xpra ("screen for X"), or NX, in which case you don't need to run
full screen.
> The main downside is performance, as Xvnc uses software rendering and
> cannot take delegate rendering to the video hardware.
For games and such you can use VirtualGL (works for both VNC and xpra),
hardware video decoding will still be missing, but for everything else I
don't think you will ever notice the difference in rendering
performance: the network/local pixel forwarding and client rendering is
much more costly than that.

Antoine
___
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

Re: Remote OpenGL -- getting it to work?

[Antoine Martin]

On 01/06/16 05:13, Thomas Lübking wrote:
> On Tue, May 31, 2016 at 08:33:14AM -0700, L. A. Walsh wrote:
>> Glynn Clements wrote:
>>> L. A. Walsh wrote:
>>>
 I have sometimes gotten some GLX programs to work for a short while,
 but more often than not, I don't get them to work at all.
>>>
>>> The most likely reason for this is that the program needs a later
>>> version of OpenGL than Cygwin's X server provides.
>> 
>>   Hmmmwhat does this mean, then?
>> OpenGL vendor string: NVIDIA Corporation
>> OpenGL renderer string: GeForce GTX 590/PCIe/SSE2
>> OpenGL version string: 1.4 (4.5.0 NVIDIA 355.98)
> 
> Indirect GL is confined to GL 1.4 (ie. fixed function path, notably no
> glsl)
> The driver and GPU support 4.5, but only on direct contexts.
> 
> You should check whether indirect GL works generally (there're somet
> pitfalls), ie. whether glxgears works.
> If so, you best contact the authors of the failing GL clients and ask
> whether they provide a fixed function path (and how to select it)
> 
> If everything else fails, you'll have to resort to eg. VNC (afair
> only x11vnc will work for you)
FWIW: xpra + virtualgl works very well and is often considerably faster
than doing GL over a remote display connection. More info here:
https://xpra.org/trac/wiki/Usage/OpenGL

Cheers
Antoine
___
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: Remote OpenGL -- getting it to work?

[Antoine Martin]

On 11/06/16 01:02, L. A. Walsh wrote:
> Antoine Martin wrote:
>>>> .0 NVIDIA 355.98)
>>>>   
>>>
>> FWIW: xpra + virtualgl works very well and is often considerably faster
>> than doing GL over a remote display connection. More info here:
>> https://xpra.org/trac/wiki/Usage/OpenGL
>>   
> ---
> Will have to try that -- not sure if xpra is supported by the cygwin/X
> server or not...
No, you do not need cygwin or anything else: the client runs native on
all supported platforms, including MS Windows.

Antoine
___
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: Remote OpenGL -- getting it to work?

[Antoine Martin]

On 11/06/16 12:30, L. A. Walsh wrote:
> Antoine Martin wrote:
>> On 11/06/16 01:02, L. A. Walsh wrote:
>>  
>>> Antoine Martin wrote:
>>>
>>>>>> .0 NVIDIA 355.98)
>>>>>> 
>>>> FWIW: xpra + virtualgl works very well and is often considerably faster
>>>> than doing GL over a remote display connection. More info here:
>>>> https://xpra.org/trac/wiki/Usage/OpenGL
>>>> 
>>> ---
>>> Will have to try that -- not sure if xpra is supported by the cygwin/X
>>> server or not...
>>> 
>> No, you do not need cygwin or anything else: the client runs native on
>> all supported platforms, including MS Windows.
>>   
> ---
>And it includes the X-server as well?
Not sure what "it" is.
Xpra uses a virtual display server (Xvfb or Xorg+dummy) on the server
side, which is provided by your distribution.
On the client side, it runs *native* via GTK: so no need for X11 on MS
Windows or Mac OSX.

Cheers
Antoine
___
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: emit "smooth scrolling/pixel perfect" events

[Antoine Martin]

On 05/01/15 06:52, Peter Hutterer wrote:
> On Mon, Dec 29, 2014 at 08:07:31PM +0100, dustin wrote:
>> Hi,
>>
>> i recently started to play around with the input facilitys of X. My goal is
>> to develop a remote control for my PC and for that purpose i want to control
>> the mouse with an android tablet. (Maybe other embeded devices)
>>
>> I found a few ways to do this namely xtest and uinput/evdev (and untested
>> xlib/xcb). Both working out of the box but i think i'll stick with
>> uinput/evdev cuz i think this approach should work with libinput(wayland) as
>> well? One problem arises that i can't circumvent and this is the scrolling.
>> my first implementation works by simply emitting button 4/5 events like what
>> ordinary mouse wheels do (looking at xev xinput tools) but what i am rally
>> looking for is emitting "smooth scroll events"/"pixel perfect scrolling"
>> (whatever this means). I came across some articles from Peter Hutterer
>> talking about this and that Gnome implemented this. One can see this in live
>> action via touchpad and the epiphany webbrowser. What i discovered was, that
>> a client program has to catch XI2 events (XIDeviceEvent)and watch for
>> XI_Motion and its valuators. But i really don't know how to emit these? with
>> uinput/evdev even if i am emiting EV_REL, REL_WHEEL events and not button
>> 4/5 events i got ordinary scrolling. what is the "right way" to emit these
>> XIDeviceEvent/XI_Motion events (if these are really the ones i am looking
>> for)
>>
>> what i was seeing from xinput --test-xi2 for ordinary mouse wheels was
>>
>> EVENT type 17 (RawMotion)
>>device: 2 (10)
>>detail: 0
>>valuators:
>>flags:
>>  2: -1.00 (-1.00)
>>
>> EVENT type 15 (RawButtonPress)
>>device: 2 (10)
>>detail: 5
>>valuators:
>>flags: emulated
>>
>> EVENT type 16 (RawButtonRelease)
>>device: 2 (10)
>>detail: 5
>>valuators:
>>flags: emulated
>>
>> As i understand this right the first XI_RawMotion is the "now" the regular
>> new event and the button presses are for compatibility and can be ignored
>> cuz of the "emulated" flag
>>
>> the valuator 2 means
>>
>> Class originated from: 10. Type: XIValuatorClass
>>Detail for Valuator 2:
>>  Label: Rel Vert Wheel
>>  Range: -1.00 - -1.00
>>  Resolution: 1 units/m
>>  Mode: relative
>>
>> if i scroll with my touchpad i get
>>
>> EVENT type 17 (RawMotion)
>>device: 2 (13)
>>detail: 0
>>valuators:
>>flags:
>>  3: 4.00 (4.00)
>>
>> there i have a valuator 3 which i guess means Rel Vert Scroll regarding to
>> this
>>
>> Class originated from: 13. Type: XIValuatorClass
>>Detail for Valuator 3:
>>  Label: Rel Vert Scroll
>>  Range: 0.00 - -1.00
>>  Resolution: 0 units/m
>>  Mode: relative
>>
>> So the difference must somehow be with the different valuators. If so i just
>> don't know how i can influence this with uinput/evdev. Maybe its only doable
>> with xlib/xcb/xtest etc. i don't know.
>>
>> all i want is to simulate the "pixel perfect smooth scrolling" i get from
>> regular laptop touchpads so that apps who respond to this will do from my
>> application.
> 
> the output of xinput should also include a XIScrollClass. That contains
> information whether it's vertical/horizontal and refers to the valuator
> number. If such a class is present, the valuator listed is a scrolling
> valuator and should be interpreted as such.
> 
> You don't have to do anything special in uinput, just send REL_WHEEL and the
> rest of the xorg stack will do the right thing. Though since REL_WHEEL is
> discreet, you won't get as much use out of smooth scrolling as you would
> from a touchpad.
When I send REL_WHEEL via uinput, applications that normally do smooth
scrolling (ie: a browser) will scroll a few lines of text at a time, as
if I had used the wheel using my mouse. That's expected.

What I would like to be able to do is emulate the behaviour I get from
my trackpad with two-finger scrolling.

I was hoping that simply setting uinput's absmax would have an effect on
the valuator that gets assigned but this makes no difference.
I assume that I need to get uinput to emulate a more "complete" device,
but all my attempts have failed so far.
Any ideas?

Thanks
Antoine


> 
> Cheers,
>Peter
> ___
> 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
> 

___
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.

[Antoine Martin]

On 29/11/16 05:03, Gene Heskett wrote:
> 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.
As other have pointed out, SSH will add some latency.
On top of that, many applications will use synchronous X11 calls which
will just kill your framerate. Try an X11 proxy to decouple the client
applications from the X11 server.
ie: (shameless plug), from your client:
xpra start ssh:ARMSERVER --start=xterm
(you will probably need to tune it for low power CPUs like arm, ie: turn
off compression)

Cheers
Antoine



> 
>> 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
> 

___
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.

[Antoine Martin]

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.

> 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.

If you exclude the 4k fullscreen video use case - which is a worst case
scenario for remote display (there are tricks to deal with that too if
you are willing to make sacrifices), then screen updates are actually
much more manageable, even on a 1Gbps shared link.

Cheers
Antoine


> 
>>> 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 
>> ___
>> 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: Question about X on the arm's.

[Antoine Martin]

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 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

Re: Question about X on the arm's.

[Antoine Martin]

On 29/11/16 14:40, Alan Coopersmith wrote:
> 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.
> 
xpra maintainer here... don't forget about us!

Cheers
Antoine

http://xpra.org/
___
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.

[Antoine Martin]

On 29/11/16 13:04, Gene Heskett wrote:
> 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
>>> 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 s

Re: Question about X on the arm's.

[Antoine Martin]

 If you exclude the 4k fullscreen video use case - which is a worst case
 scenario for remote display (there are tricks to deal with that too if
 you are willing to make sacrifices), then screen updates are actually
 much more manageable, even on a 1Gbps shared link.
>>>
>>> nope. not really. do the math. buy a few arm dev boards. :) find out that
>>> you won't get 1gigabit. even 100mbit is pushing things.
>> 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 not talking video streams. we're talking x11.
I believe the OP's requirement is to run an X11 application on one
system and display it on the arm system, at a better framerate than is
being offered currently by X11-over-ssh.

Or at least, that's the angle I choose to see since that's exactly what
xpra does ;)

Seriously, we're not just a little bit proud of the fact that users have
a relatively smooth experience with 4K monitors over 100Mbps connections
considering that their display link will top 25Gbps.
It took years of effort and we're finally releasing a v1.0 this week.

> and with x11 to push
> pixels across a network basically means xputimage and that means the bandwidth
> requirements i have given (or sending the draw calls and as discussed this is
> pretty much dead for various reasons).
IME, users usually don't care much about what transport is used as long
as the solution satisfies their requirements.

>> And obviously, if you want lossless you probably aren't doing 20fps.
>> At this point it is probably best to ask the OP exactly *what* he needs
>> forwarded at 20fps.
>>
>>> the days where your clients upload some monochrome 1 bit bitmaps and then
>>> just render with xfillarc/xcopyarea etc. etc. are kind of over.
>> Definitely over.
>>
>>> today data is 32bpp
>>> with lots of new client-side generated data all the time and mopre and more
>>> clients try and use opengl to get acceleration and speed and that's really a
>>> local-only thing these days. yes i know of glx indirect rendering. get that
>>> to work over a network to an arm board which is egl/gles... :)
>> Yes, that's exactly the use cases that we handle.
>>
>> Cheers
>> Antoine
>>
>> http://xpra.org/
> 
> xpra is its own display system effectively separate from x11.
Sort of. Nitpick: Xpra is an X11 compositing window manager and we use a
completely stock / unmodified / distro supplied X11 server, the clients
are native however (X11, OpenGL, HTML5) and the wire protocol has
nothing to do with X11 at all.

Cheers
Antoine

> at least in terms
> of display as x11 protocol supports no forms of compression (let along lossy
> compression) of pixel data. xpra is a separate display tech much like rdp,
> miracast, vnc etc. would be. :)

___
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.

[Antoine Martin]

On 29/11/16 18:52, Gene Heskett wrote:
> On Tuesday 29 November 2016 04:18:09 Antoine Martin wrote:
> 
>>>>>> If you exclude the 4k fullscreen video use case - which is a
>>>>>> worst case scenario for remote display (there are tricks to deal
>>>>>> with that too if you are willing to make sacrifices), then screen
>>>>>> updates are actually much more manageable, even on a 1Gbps shared
>>>>>> link.
>>>>>
>>>>> nope. not really. do the math. buy a few arm dev boards. :) find
>>>>> out that you won't get 1gigabit. even 100mbit is pushing things.
>>>>
>>>> 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 not talking video streams. we're talking x11.
>>
>> I believe the OP's requirement is to run an X11 application on one
>> system and display it on the arm system, at a better framerate than is
>> being offered currently by X11-over-ssh.
> 
> Slight correction, the application that is generating the image data, is 
> running on the pi 3b, the system doing the viewing and control, is to 
> run on the odroid-c2, which does have the gfx horsepower and memory to 
> do it.
Oh, OK. Then you may want to look into VirtualGL.

Cheers
Antoine


> 
> It also has 4 gpu's, which are so new that linux & X does not use them 
> ANAICT. But I'd assume its the future for these arm based SBC'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: How to avoid this Xvfb error: ES2 Prism: Error - GLX extension is not supported

[Antoine Martin]

On 12/12/16 19:51, Long Vu wrote:
> On Mon, Dec 12, 2016 at 1:06 PM, Long Vu  wrote:
>> On Mon, Dec 12, 2016 at 12:20 PM, Adam Jackson  wrote:
>>> On Mon, 2016-12-12 at 12:13 -0500, Long Vu wrote:
>>>
 Would it be this xvfb-run option ?

 -s ARGS   --server-args=ARGSarguments (other than server number and
 "-nolisten tcp") to pass to the Xvfb 
 server
 (default: "-screen 0 640x480x8")

 I am not familiar with X server options, what server args I would need
 to get rid of this "ES2 Prism: Error - GLX extension is not supported"
 error?
>>>
>>> Yes, I think it would be:
>>>
>>> xvfb-run -s "-screen 0 640x480x24" # ... whatever else you use
>>
>> I tried xvfb-run -s "-screen 0 640x480x24", still the same error.  Any
>> other clues?
>>
>> ES2 Prism: Error - GLX extension is not supported
>> GLX version 1.3 or higher is required
>> Xlib:  extension "RANDR" missing on display ":99".
>>
>>
>> Now that I run at 24 bpp, maybe I should force GLX to be enabled?  Or
>> have to specify a GLX version, otherwise the default is less than 1.3?
>>
> 
> I bumped the resolution and manually try to enable GLX, still the same error.
> 
> xvfb-run -s '-screen 0 1024x768x24 +extension GLX +iglx' 
> 
> I don't know what else to try.
Your Xvfb on CentOS will not support the GL extension.
If you really must use OpenGL with your client applications:
1) Use Xdummy
https://xpra.org/trac/wiki/Xdummy
2) Use VirtualGL
http://www.virtualgl.org/

Cheers
Antoine
___
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 avoid this Xvfb error: ES2 Prism: Error - GLX extension is not supported

[Antoine Martin]

On 12/12/16 20:37, Roland Mainz wrote:
> On Mon, Dec 12, 2016 at 8:27 PM, Antoine Martin  wrote:
>> On 12/12/16 19:51, Long Vu wrote:
>>> On Mon, Dec 12, 2016 at 1:06 PM, Long Vu  wrote:
>>>> On Mon, Dec 12, 2016 at 12:20 PM, Adam Jackson  wrote:
>>>>> On Mon, 2016-12-12 at 12:13 -0500, Long Vu wrote:
>>>>>
>>>>>> Would it be this xvfb-run option ?
>>>>>>
>>>>>> -s ARGS   --server-args=ARGSarguments (other than server number 
>>>>>> and
>>>>>> "-nolisten tcp") to pass to the Xvfb 
>>>>>> server
>>>>>> (default: "-screen 0 640x480x8")
>>>>>>
>>>>>> I am not familiar with X server options, what server args I would need
>>>>>> to get rid of this "ES2 Prism: Error - GLX extension is not supported"
>>>>>> error?
>>>>>
>>>>> Yes, I think it would be:
>>>>>
>>>>> xvfb-run -s "-screen 0 640x480x24" # ... whatever else you use
>>>>
>>>> I tried xvfb-run -s "-screen 0 640x480x24", still the same error.  Any
>>>> other clues?
>>>>
>>>> ES2 Prism: Error - GLX extension is not supported
>>>> GLX version 1.3 or higher is required
>>>> Xlib:  extension "RANDR" missing on display ":99".
>>>>
>>>>
>>>> Now that I run at 24 bpp, maybe I should force GLX to be enabled?  Or
>>>> have to specify a GLX version, otherwise the default is less than 1.3?
>>>>
>>>
>>> I bumped the resolution and manually try to enable GLX, still the same 
>>> error.
>>>
>>> xvfb-run -s '-screen 0 1024x768x24 +extension GLX +iglx' 
>>>
>>> I don't know what else to try.
>> Your Xvfb on CentOS will not support the GL extension.
>> If you really must use OpenGL with your client applications:
>> 1) Use Xdummy
>> https://xpra.org/trac/wiki/Xdummy
>> 2) Use VirtualGL
>> http://www.virtualgl.org/
> 
> Correction:
> The version of Xvfb he is using has been compiled without GLX support
> and he "just" needs to recompile his own version with GLX support
> enabled...
For most people, using a different command line (Xdummy's or virtualgl
instead of Xvfb) will be a lot easier than recompiling the X11 server.
Especially for managing multiple deployments or handling system updates.

Cheers
Antoine

> 
> 
> Bye,
> Roland
> 

___
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: xserver-xorg-video-dummy driver XORG and X11vnc on Android chroot

[Antoine Martin]

On 30/01/2020 17:17, Mgr. Janusz Chmiel wrote:
> Here you can find xorg.conf which I Am using.
> 
> https://gist.github.com/divinity76/ce210b5dbcd9ea7d0585ac403caef577
It appears that this dummy configuration file you are using is based on
the one I made for xpra.
> May be, that it would be possible to find some virtual console which would
> give XOrg routines The impression that real console exists, but I do not
> think that some similar package will exist.
You're not specifying the exact problem that you encountered, but based
on past experience with Xdummy, it is likely to be because you are
running the "wrong" Xorg, ie:
https://unix.stackexchange.com/a/565257/13286
See also:
https://wiki.archlinux.org/index.php/Xpra#Error:_Only_console_users_are_allowed_to_run_the_X_server

Antoine
___
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: 30-bit X session and programs requiring 24-bit depth

[Antoine Martin]

On 14/02/2020 18:53, Marek Szuba wrote:
> Hello,
> 
> I do quite a lot of photo editing on my box and with both my monitors
> and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
> to run X at colour depth 30. Unfortunately some software, most notably
> programs using OpenGL it seems, refuse to run in this mode - presumably
> (I have seen this mentioned as the reason of problems with 30-bit mode
> under Windows when the first cards supporting it came out) because the
> software assumes 8-bit alpha channel but with the frame buffer still
> being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
> switching colour depth on the fly, the best I have been able to come up
> with is two separate X sessions - one at depth 30 and one at 24.
> 
> Is there, or perhaps will there be some way in the near future, to work
> around this problem - either by increasing framebuffer BPP (tried it a
> while ago but it didn't seem to accept anything more than 32), using a
> virtual X server (tried using Xephyr but it complained about there being
> no matching screen), or some other way I haven't thought of?
If you don't mind the indirection this introduces:
xpra start --start=xterm --attach=yes
This will start your application (ie: xterm) on a 24-bit virtual
framebuffer and display it on your local 30-bit display.
The pixel depth upscaling will be done by your OpenGL driver, or failing
that, in software.

The reverse is also possible, with a local display at 24-bit:
xpra start --start=xterm --attach=yes --pixel-depth=30
Runs the app on a 30 bit virtual display.
Apparently, there are apps that require a 30-bit display to use GPU
image processing and some users don't care if they don't actually see
the extra bit depth when doing so.

Antoine

> 
> Thank you in advance for your comments.
> 

___
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: 30-bit X session and programs requiring 24-bit depth

[Antoine Martin]

On 17/02/2020 15:51, Ilya Anfimov wrote:
> On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote:
>> On 14/02/2020 18:53, Marek Szuba wrote:
>>> Hello,
>>>
>>> I do quite a lot of photo editing on my box and with both my monitors
>>> and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
>>> to run X at colour depth 30. Unfortunately some software, most notably
>>> programs using OpenGL it seems, refuse to run in this mode - presumably
>>> (I have seen this mentioned as the reason of problems with 30-bit mode
>>> under Windows when the first cards supporting it came out) because the
>>> software assumes 8-bit alpha channel but with the frame buffer still
>>> being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
>>> switching colour depth on the fly, the best I have been able to come up
>>> with is two separate X sessions - one at depth 30 and one at 24.
>>>
>>> Is there, or perhaps will there be some way in the near future, to work
>>> around this problem - either by increasing framebuffer BPP (tried it a
>>> while ago but it didn't seem to accept anything more than 32), using a
>>> virtual X server (tried using Xephyr but it complained about there being
>>> no matching screen), or some other way I haven't thought of?
>> If you don't mind the indirection this introduces:
>> xpra start --start=xterm --attach=yes
>> This will start your application (ie: xterm) on a 24-bit virtual
>> framebuffer and display it on your local 30-bit display.
> 
>  And with software-only OpenGL.
If you want accelerated OpenGL within the xpra session, use VirtualGL:
https://xpra.org/trac/wiki/Usage/OpenGL
ie:
xpra start --start="vglrun xterm" --attach=yes
>  xpra itself is not really good at either proxying or accelerating
> glx/dri.
Xpra doesn't even attempt to do these things, that's not its job.

Antoine


> 
> 
> 
>> The pixel depth upscaling will be done by your OpenGL driver, or failing
>> that, in software.
>>
>> The reverse is also possible, with a local display at 24-bit:
>> xpra start --start=xterm --attach=yes --pixel-depth=30
>> Runs the app on a 30 bit virtual display.
>> Apparently, there are apps that require a 30-bit display to use GPU
>> image processing and some users don't care if they don't actually see
>> the extra bit depth when doing so.
>>
>> Antoine
>>
>>>
>>> Thank you in advance for your comments.
>>>
>>
>> ___
>> 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: 30-bit X session and programs requiring 24-bit depth

[Antoine Martin]

On 17/02/2020 16:40, Ilya Anfimov wrote:
> On Mon, Feb 17, 2020 at 04:01:35PM +0700, Antoine Martin wrote:
>> On 17/02/2020 15:51, Ilya Anfimov wrote:
>>> On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote:
>>>> On 14/02/2020 18:53, Marek Szuba wrote:
>>>>> Hello,
>>>>>
>>>>> I do quite a lot of photo editing on my box and with both my monitors
>>>>> and my graphics card (amdgpu) supporting 10-bit colour channels, I tend
>>>>> to run X at colour depth 30. Unfortunately some software, most notably
>>>>> programs using OpenGL it seems, refuse to run in this mode - presumably
>>>>> (I have seen this mentioned as the reason of problems with 30-bit mode
>>>>> under Windows when the first cards supporting it came out) because the
>>>>> software assumes 8-bit alpha channel but with the frame buffer still
>>>>> being only 32-bit it is only 2-bit. Seeing as there seem to be no way of
>>>>> switching colour depth on the fly, the best I have been able to come up
>>>>> with is two separate X sessions - one at depth 30 and one at 24.
>>>>>
>>>>> Is there, or perhaps will there be some way in the near future, to work
>>>>> around this problem - either by increasing framebuffer BPP (tried it a
>>>>> while ago but it didn't seem to accept anything more than 32), using a
>>>>> virtual X server (tried using Xephyr but it complained about there being
>>>>> no matching screen), or some other way I haven't thought of?
>>>> If you don't mind the indirection this introduces:
>>>> xpra start --start=xterm --attach=yes
>>>> This will start your application (ie: xterm) on a 24-bit virtual
>>>> framebuffer and display it on your local 30-bit display.
>>>
>>>  And with software-only OpenGL.
>> If you want accelerated OpenGL within the xpra session, use VirtualGL:
>> https://xpra.org/trac/wiki/Usage/OpenGL
>> ie:
>> xpra start --start="vglrun xterm" --attach=yes
>  
> 
>   If  virtualgl  could  be used -- then yes, but then there is no
> need in xpra.
VirtualGL will tunnel 32-bit / 30-bit rendering to a real GPU but it
won't change the X11 visuals that the application sees when connecting
to the X11 server, and when applications fail to render at 30-bit it is
usually because they can't find a matching X11 visual, not a GL visual.
30-bit displays will happily give you regular 24/32-bit OpenGL rendering
contexts.

Antoine

>   virtualgl itself has some other thin moments.
> 
>>>  xpra itself is not really good at either proxying or accelerating
>>> glx/dri.
>> Xpra doesn't even attempt to do these things, that's not its job.
> 
>  Well, I don't agree with that either, but the result is the same.
> 
___
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: Dummy video driver plea

[Antoine Martin]

On 12/05/2020 15:21, Mgr. Janusz Chmiel wrote:
> Here is xorg.conf which I Am using.
> 
> https://gist.github.com/divinity76/ce210b5dbcd9ea7d0585ac403caef577
> Which line of this file define so big resolution?
In that file, all the lines starting with "Modeline" define the
resolutions available with the dummy driver.

Unless you specify a different bit depth, the server will start with a
depth of 24.
So look for the 'SubSection "Display"' with a depth of 24.
The resolution used will be the first valid one from the "Modes" list.
(you can just comment out the "Virtual" size which just complicates
things for your use case)

This is all documented in "man xorg.conf".

Otherwise, you can also start with the default resolution and change it
later with xrandr, ie run:
xrandr -s 1024x768

> Or it is only A warning of
> Mochavnc which so not make sense at all? Is it only wrong VNC protocoal
> analysis results, which author of MochVNC have used?
I have no idea about mochavnc.

Cheers,
Antoine
___
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: Window id of xterm started

[Antoine Martin]

On 10/02/2024 19:53, Riza Dindir wrote:

Hello,

I am starting xterm in my xinitrc. Is it possible to get the window id 
of that xterm?
No-one has mentioned this solution yet, so for completeness I'll throw 
it in:
XResQueryClientIds can be used to query the real pid of window. Unlike 
`_NET_WM_PID`, it can't be faked or modified.
You can get the pid of your xterm when you start it (ie: using $?), then 
find the window(s) that match it.


Cheers,
Antoine




Regards

Re: XChangeProperty/XGetWindowProperty problem

[Antoine Martin]

You're using using format=32, which means `CARD32` aka `unsigned long`, 
not to be confused with 32-bit integers, despite its name.

Switch from `int32_t` to `unsigned long`.

Cheers,
Antoine

On 09/05/2025 13:56, 406643764 wrote:

Hi, all.
I use XChangeProperty/XGetWindowProperty as following code:
#include 
#include 
#include 

int main(void)
{
     Display *display=XOpenDisplay(NULL);
     int screen=DefaultScreen(display);
     Window root_win=RootWindow(display, screen);

     Window win=XCreateSimpleWindow(display, root_win, -1, -1, 1, 1, 0, 
0, 0);

     Atom prop=XInternAtom(display, "test_prop", False);
     Atom type=XInternAtom(display, "test_type", False);
     int32_t a[]={0x11223344, 0x55667788};
     XChangeProperty(display, win, prop, type, 32, PropModeReplace, 
(unsigned char *)a, 2);


     int fmt;
     unsigned long nitems=0, n=0, rest;
     unsigned char *p=NULL;
     Atom atype;
     if( XGetWindowProperty(display, win, prop, 0, 2, False,
     type, &atype, &fmt, &n, &rest, &p) != Success
     || !atype || !fmt || !n || !p)
     XFree(p), p=NULL;
     long *d=(long *)p;
     printf("%lx, %lx, %lu\n", d[0], d[1], rest);

     XCloseDisplay(display);

     return 0;
}

But the output is:

11223344, 1, 0

It should be:

11223344, 55667788, 0

What's wrong ?



406643764
406643...@qq.com