Re: [PATCH xserver v3] xwayland: Fix use after free of cursors

[Olivier Fourdan]

Hi,

> > Sometimes, Xwayland will try to use a cursor that has just been freed,
> > leading to a crash when trying to access that cursor data either in
> > miPointerUpdateSprite() or AnimCurTimerNotify().
> > 
> > CheckMotion() updates the pointer's cursor based on which xwindow
> > XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
> > to fake a crossing to the root window when the pointer has left the
> > Wayland surface but is still within the xwindow.
> > 
> > But after an xwindow is unrealized, the last xwindow used to match the
> > xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
> > not return the same xwindow.
> > 
> > To avoid this issue, update the last_xwindow based on enter and leave
> > notifications instead of xwl_xy_to_window(), and check if the xwindow
> > found by the regular miXYToWindow() is a child of the known last
> > xwindow, so that multiple consecutive calls to xwl_xy_to_window()
> > return the same xwindow, being either the one found by miXYToWindow()
> > or the root window.
> > 
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258
> > Signed-off-by: Olivier Fourdan 
> 
> Tested-by: Vít Ondruch 
> Tested-by: Satish Balay 

I have added this patch to the Fedora 25 package for 
xorg-x11-server-Xwayland-1.19.0 a week or so ago and haven't spotted any new 
report of a similar crash in Xwayland since then, so I am quite confident this 
is the right fix for the issue.

Cheers,
Olivier.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

raspian, jessie full install on a raspi 3b, mouse in heavy syrup.

[Gene Heskett]

Greetings all;

I've no clue if any of you are familar with raspian, built for the armhf 
SBC's..

I just installed it, and I am pleasantly surprised, it does almost 
everything well, except:

When the mouse is moved, there is a huge lag, taking a fat second to move 
the pointer to the new location, like there is a low pass filter in the 
data path between the mouses data coming into the usb port, and where 
its fed into X. There is a tuning utility for kbd and rodent, and it 
does seem to have some slight effect on how it moves but the extremes of 
the two sliders have no effect on this moving in cold molasses motion.  
Its very distracting, taking around 4 to 6 seconds to do something with 
the mouse, that I can do in a second or less on a Dell 6 feet away 
running a milling machine.

Clues checked, url's read etc.

Thanks all.

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

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 03:39:51 Thomas Lübking wrote:

> On Mon, Nov 28, 2016 at 11:59:26PM -0500, Gene Heskett wrote:
> >root   797  0.0  1.9 271380 33600 tty7 Ssl+ 20:50
> >0:02 /usr/lib/xorg/Xorg -core :0 -seat
> >seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
> >
> >gene  4114  0.0  0.0   5564   908 pts/8S+   23:48   0:00
> >grep --color=auto listen
> >
> >builders took advantage of that to get rid of 100k of object code. 
> > So I have challenged the odroid people to actually make it work.
>
> Got any clue on this or just a hunch? There's an explicit nolisten
> switch that didn't end up there magically but will oc. prevent tcp
> access for sure.
>
> >That server starts automatically.
>
> That's the "problem" - ask the odroid people about "automatically"
> (i've no experience with that system, sorry)
>
> >The line that starts it, xinit/xsessionrc specifically says -listen
> > tcp as an argument for /usr/bin/X
>
> I doubt the call is simply altered from listen to nolisten.
> Pass it some unexpected bullshit argument ("-gnarf") and see whether
> that has some impact - otherwise i'd say whatever starts X in that
> environment doesn't care about xinit/xsessionrc at all.
>
> Cheers,
> Thomas

Well, the droid may have a place sometime in the future, but at the 
moment it has been such a pain in my rear that it was popped of the 
panel, disconnected from the psu, and tossed on a high shelf.

I had been instructed to originally install the jessie-lite version of 
raspian, but I went back to the site and pulled the full install image, 
and wrote that to the u-sd card. sync'd it, then unplugged it and 
plugged it back in and the automount dutifully mad it available 
as /media/usb1 and /media/usb2.

So I dived into the /etc directory and installed my network setup, and 
made myself user 1000:1000, changing the name pi to gene anyplace I 
found it, making me the first user like I shoulda been in the first.

And of course I forgot to make the network stuff immutable, so N-M 
destroyed it, as usual. A couple root sessions with nano, followed by 
some chattr +i on resolv.conf and interfaces fixed all that up. I'll 
have to see if I can remove that POS, but at least it can't cripple me 
again.

This boots to a gui they call PIXEL, fair, needs some colors adjusted.

I upgraded it to the latest, then installed synaptic since I couldn't 
make out which end of the horse their package manager was faceing me.

I had saved the ~/linuxcnc directory out, and wrote it back to my new 
$home directory, and I installed the bleeding edge linuxcnc.

modprobed the spi stuff into memory, fired up linuxcnc, and the interface 
card responded properly to the spi from linuxcnc, reporting a full list 
of its capabilities. So I loaded up a program to carve a chess pawn, 
homed it and hit the r key.  And was blown away, it was running at about 
a 20 frame/second display rate! With nothing plugged into the droid, the 
raspi 3b was doing it all. No worries about whether or not x was 
listening on a tcp port (its not according to htop).  Put the modprobed 
stuff into the load list file in /etc/modules. Rebooted, and it still 
Just Works(TM).

I am indeed pleased. I might even sleep well tonight.  Now to get the 
rest of it built & wired up.

And in about 30 minutes amanda will see if it can back that puppy up. The 
checker didn't fuss, so I believe that will work.

Only one problem, which I'll pose as a separate post.

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

[Bug 94811] ATI radeon driver displays nothing or a client refused to switch message on hybrid graphics

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94811

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #14 from Michel Dänzer  ---
(In reply to Saurav from comment #13)
> What I was looking for would be a way to make the radeon driver
> do the offloading automatically without having to manually set DRI_PRIME=1.

FWIW, with DRI3, you can enable PRIME offloading via ~/.drirc, either for all
applications (but note that doing so will likely break the compositing manager,
because GLX_EXT_texture_from_pixmap isn't supported with PRIME offloading) or
for individual applications.

Also, current versions of GNOME (as available e.g. in Fedora 25) allow enabling
PRIME offloading in the launcher application properties.

Anyway, there's no Xorg radeon driver bug here, resolving accordingly.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: Question about X on the arm's.

[Thomas Lübking]

On Mon, Nov 28, 2016 at 11:59:26PM -0500, Gene Heskett wrote:


root   797  0.0  1.9 271380 33600 tty7 Ssl+ 20:50
0:02 /usr/lib/xorg/Xorg -core :0 -seat
seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

gene  4114  0.0  0.0   5564   908 pts/8S+   23:48   0:00
grep --color=auto listen



builders took advantage of that to get rid of 100k of object code.  So I
have challenged the odroid people to actually make it work.

Got any clue on this or just a hunch? There's an explicit nolisten
switch that didn't end up there magically but will oc. prevent tcp
access for sure.


That server starts automatically.

That's the "problem" - ask the odroid people about "automatically" (i've
no experience with that system, sorry)


The line that starts it, xinit/xsessionrc specifically says -listen tcp
as an argument for /usr/bin/X


I doubt the call is simply altered from listen to nolisten.
Pass it some unexpected bullshit argument ("-gnarf") and see whether
that has some impact - otherwise i'd say whatever starts X in that
environment doesn't care about xinit/xsessionrc at all.

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

[ANNOUNCE] libdrm 2.4.74

[Robert Bragg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Ben Widawsky (1):
  intel: Add Geminilake PCI IDs

Christian Gmeiner (4):
  etnaviv: add API to get drm fd from etna_device
  etnaviv: add API to create etna_device from private dup() fd
  etnaviv: change get_abs_timeout(..) to use ns.
  etnaviv: add etna_pipe_wait_ns(..)

Emil Velikov (2):
  automake: make the build less chatty
  xf86drm: introduce drmGetDeviceNameFromFd2

Eric Anholt (1):
  vc4: Add new GETPARAMs that have been merged to drm-next.

Grazvydas Ignotas (2):
  tests: kms: fix shadowed declaration warning
  libdrm: random typo fixes

Michel Dänzer (1):
  intel: Add drm_intel_gem_context_get_id to intel-symbols-check

Rob Clark (1):
  freedreno: 64bit support

Robert Bragg (2):
  intel: Add a getter for the intel_context ctx_id
  Bump version for release

git tag: libdrm-2.4.74

https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.bz2
MD5:  31964aa15bdea1a40c5941d4ce0962ee  libdrm-2.4.74.tar.bz2
SHA1: 0d9c02d5d2c6c2fac862cb687bf45bc20d129017  libdrm-2.4.74.tar.bz2
SHA256: d80dd5a76c401f4c8756dcccd999c63d7e0a3bad258d96a829055cfd86ef840b  
libdrm-2.4.74.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.gz
MD5:  b661a54514109caad3de3b520680b98e  libdrm-2.4.74.tar.gz
SHA1: 7b5a80fbdd432e87934ef3b1256a58ed7b034574  libdrm-2.4.74.tar.gz
SHA256: 3c8fdf5a89826797a8060e6f3455ca22db9ae49576cfcda1c78e3e2ce59af0f1  
libdrm-2.4.74.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.74.tar.gz.sig

-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlg9iT0ACgkQjNHfVSl1KXvN2QCfSj1H53aYHdMVMUN2B64FVF5E
n0QAn0Fn3jDlrl6lpdbTJO3Mclg9WFUZ
=+4Tx
-END PGP SIGNATURE-
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: XOpenDisplay call sequence

[Aaron Plattner]

On 11/28/2016 01:31 PM, Krzywicki, Alan wrote:
>
> So if I follow the XOpenDisplay sequence up the stack I see
> xcb_connect() / _/xcb_open/_abstract( ) trying to open
> “/tmp/.X11-unix/X0” with protocol set to 0.   On one system it
> eventually calls select(), on another it uses poll() instead, so it is
> looking for a response.  Once in a while it takes over a minute to get
> a response.   Can anyone describe a general overview of what it is
> trying to open?  Any idea why the select/poll call hangs so long?
>
>  
>
> Stack example:
>
>  
>
> #0  0xe424 in __kernel_vsyscall ()
> #1  0xb6ad657d in select () from /lib/i686/libc.so.6
> #2  0xb68997fc in ?? () from /usr/lib/libxcb.so.1
> #3  0xb68985db in xcb_connect_to_fd () from /usr/lib/libxcb.so.1
> #4  0xb689b6cd in xcb_connect () from /usr/lib/libxcb.so.1
> #5  0xb7004b9b in _XConnectXCB () from /usr/lib/libX11.so.6
> #6  0xb6fe5f10 in XOpenDisplay () from /usr/lib/libX11.so.6
> #7  0x0805f463 in main ()
>
>  
>
My guess is that the missing stack frames are

#2.0 read_block()
#2.1 _xcb_in_read_block()
#2.2 read_setup()

If that's where it's blocked, then it's waiting for the server to send
the setup block. Either the server is busy processing another client's
request, or some other client grabbed the server and hasn't ungrabbed it
yet. You'll have to debug the server to see whether it's stuck too or if
/ why it chose not to send the connection block.
>
>  
>
> / Alan K.
>
> ---
> This communication contains confidential information. If you are not
> the intended recipient please return this email to the sender and
> delete it from your records.
>
> Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht
> der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte
> diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem
> System.
>
>
> ___
> 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.

[Gene Heskett]

On Tuesday 29 November 2016 13:48:07 Antoine Martin wrote:

> 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

OP here. I am in the last stretch of making a decent display to run 
linuxcnc in/on. 

I traded the jessie-lite install on the r-pi for the full install.  But I 
made several trips back to the card reader fixing this and that while it 
wasn't running, but in a couple hours, I managed to change the /home/pi 
to /home/gene, fixed the passwd, group and sudoers files up so that I am 
now user 1000 and can do as I wish.  Including using synaptic as the 
package manager.

Having the full install made a huge difference as I can now run linuxcnc 
from an xterm.  And it runs at around 15 to 20 updates a second, all on 
the r-pi. I can tolerate that with one exception, the mouse is on a 
flexible hose, running around in cold molasses. You move it, using 
muscle memory, and even an inch on screen takes around a second for the 
mouse pointer to get to where you moved it to. It just sort of ooozes 
off in the general direction, then you look, and wait for it to stop
  
so you can make the final move in the direction toward what you want to 
hit.  Wierd.  But that definitely needs fixed.

Everything else is ah & greasy hands at this point, its ALL 
running on the raspberry3b, fast enough to be usable.

ATM both my back (old age and arthritis) and my arm hurts, the arm from 
patting myself on the back. ;-)

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

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

[Alan Coopersmith]

On 11/29/16 12:35 AM, Antoine Martin wrote:

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!


I didn't realize you used a protocol that offered compression in xpra,
but then my knowledge of xpra is mainly to answer IRC questions about
detaching & re-attaching to sessions with a suggestion they check xpra out.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

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.

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.

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

Precisely. Git-r-done at a usable/reasonable frame rate.

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


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

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 03:24:35 Carsten Haitzler wrote:

> On Tue, 29 Nov 2016 10:58:37 +0700 Antoine Martin 
 said:
[...]
> > http://xpra.org/
>
> xpra is its own display system effectively separate from x11. 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. :)

This also sounds appealing. I'll see if its available for both of these 
beasts.

Thanks.

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

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 02:40:45 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.

Since we are talking about my needs, and you mention vnc, its now part of 
the latest raspian download, which I didn't have yet, but the iso is 
trickling in now. It is not part of the odroids ubtuntu-16.04 LTS 
install so I'll have to see about how to acquire the free home version.

That assumes that it can function in the presence of a x server on the 
droid whose listen function is turned off, presumably by removing the 
code.  Can it?

Thanks.

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

[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98897

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
 QA Contact|xorg-t...@lists.x.org   |
Product|xorg|DRI
   Assignee|xorg-driver-ati@lists.x.org |dri-devel@lists.freedesktop
   ||.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver] Xi: when creating a new master device, update barries for all clients

[Daniel Stone]

Hi,

On 11 November 2016 at 05:33, Peter Hutterer  wrote:
> The previous code only worked when the barrier was created by the same client
> as the one calling XIChangeDeviceHierarchy.

Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[Bug 98897] New: Macbook pro 11,5 screen flicker when AC adapter plugged in

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98897

Bug ID: 98897
   Summary: Macbook pro 11,5 screen flicker when AC adapter
plugged in
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/Radeon
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: t...@r.je
QA Contact: xorg-t...@lists.x.org

I originally posted this at kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=189231 but was instructed to post
it here.

As of recent kernels (Sorry I don't have the exact number but at least 4.8.8)
there is problem with the screen flickering on a Macbook Pro 11,5.

There's an ongoing discussion here:
https://bbs.archlinux.org/viewtopic.php?id=219442 

Machine specs:

Macbook Pro 11,5 (Retina)
Intel i7 4870HQ
Radeon  M370X (radeon graphics driver, amdgpu does not seem to be supported so
I couldn't see if its' a gpu driver issue)

I can record a video using a camera if it would be useful, but it looks like
graphical corruption, it looks like windows are being drawn at the wrong XY
coordinates on some frames, this is made worse when a window is dragged around
the screen or something on the screen requires frequent repaints such as
watching a video. 

This is something to do with the power connector. If the AC adapter is plugged
in when the machine boots or resumes from suspend or the screen turns on the
problem occurs and the flicker will happen. Removing the AC adapter does not
remove the flicker, however, if the screen turns on without the AC adapter
present then the AC adapter can be attached without causing the flicker issue.


I need to verify this but I think the flicker happens consistently if the
laptop is in a state of "Charging" with the AC adapter plugged in, too. If it's
"Charged" but the machine is suspended/resumed without the cable in then
plugged in, then the flicker is gone. This may be simply that no power is
actually going to the battery because it's flagged as "charged". It's certainly
a power related issue.


This may also be a related issue: When the power connector is attached the
laptop's temperature is very high even when idle. Without the power cable
connected, the laptop will idle around 50C (as reported by sensors). With the
power cable connected (regardless of whether the charge is 0% or 100%) the cpu
temperature will be 60-65C. The temperature issue does not correlate with the
flicker. Regardless of whether the flicker is happening, the temperature seems
unusually high while the AC adapter is connected.


additional information: I can turn on/off the flicker using radeon dynamic
power management:

echo battery > /sys/class/drm/card0/device/power_dpm_state

No flicker

echo performance > /sys/class/drm/card0/device/power_dpm_state

Flicker starts


By changing the power state to performance the flicker happens. Using "battery"
the flicker does not so it seems to be power related but not obvious. On
"balanced" dpm, the flicker sometimes happens which is probably down to the
power state.

Changing the power state does not seem to affect the temperature at all. 

radeon-pci-0100
Adapter: PCI adapter
temp1:+60.0°C  (crit = +120.0°C, hyst = +90.0°C)


Regardless of the power state the temperature is almost always exactly 60.0,
sometimes it's 59.0 but there is no noticeable temperature difference between
"battery" and "performance" and the clock speed does not seem to change

Regardless of power state, the output of `cat
/sys/kernel/debug/dri/0/radeon_pm_info` shows:


uvdvclk: 0 dclk: 0
power level 0sclk: 3 mclk: 3 vddc: 900 vddci: 850 pcie gen: 3

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

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: [PATCH xf86-input-libinput 1/3] Add a comment regarding scroll dist default values

[Hans de Goede]

Hi,

On 29-11-16 00:25, Peter Hutterer wrote:

Changed this during development because I forgot that the value actually
matters (for touchpads anyway).

Signed-off-by: Peter Hutterer 


Series looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 src/xf86libinput.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 747e84b..324bfc8 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -2928,13 +2928,19 @@ xf86libinput_pre_init(InputDriverPtr drv,

pInfo->private = driver_data;
driver_data->pInfo = pInfo;
-   driver_data->scroll.vdist = 15;
-   driver_data->scroll.hdist = 15;
driver_data->path = path;
driver_data->shared_device = shared_device;
xorg_list_append(_data->shared_device_link,
 _device->device_list);

+   /* Scroll dist value matters for source finger/continuous. For those
+* devices libinput provides pixel-like data, changing this will
+* affect touchpad scroll speed. For wheels it doesn't matter as
+* we're using the discrete value only.
+*/
+   driver_data->scroll.vdist = 15;
+   driver_data->scroll.hdist = 15;
+
if (!is_subdevice) {
if (libinput_device_has_capability(device, 
LIBINPUT_DEVICE_CAP_POINTER))
driver_data->capabilities |= CAP_POINTER;


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: Don't send KeyRelease events on wl_keyboard::leave

[Peter Hutterer]

On Thu, Nov 24, 2016 at 07:56:18PM +0100, Rui Matos wrote:
> Commits 816015648ffe660ddaa0f7d4d192e555b723c372 and
> fee0827a9a695600765f3d04376fc9babe497401 made it so that
> wl_keyboard::enter doesn't result in X clients getting KeyPress events
> while still updating our internal xkb state to be in sync with the
> host compositor.
> 
> wl_keyboard::leave needs to be handled in the same way as its
> semantics from an X client POV should be the same as an X grab getting
> triggered, i.e. X clients shouldn't get KeyRelease events for keys
> that are still down at that point.
> 
> This patch uses LeaveNotify for these events on wl_keyboard::leave and
> changes the current use of KeymapNotify to EnterNotify instead just to
> keep some symmetry between both cases.
> 
> On ProcessDeviceEvent() we still need to deactivate X grabs if needed
> for KeyReleases.
> 
> Signed-off-by: Rui Matos 

thanks, pushed

   2de37eb..5611585  master -> master

Cheers,
   Peter

> ---
> 
> v2: Daniel Stone pointed out on IRC that I should leave the early exit
> for press events, otherwise we could activate passive grabs (in
> CheckDeviceGrabs) which is wrong in this case.
> 
>  Xi/exevents.c| 22 +-
>  dix/getevents.c  |  5 -
>  hw/xwayland/xwayland-input.c |  8 ++--
>  3 files changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/Xi/exevents.c b/Xi/exevents.c
> index fc5298e..17d751e 100644
> --- a/Xi/exevents.c
> +++ b/Xi/exevents.c
> @@ -1798,15 +1798,19 @@ ProcessDeviceEvent(InternalEvent *ev, DeviceIntPtr 
> device)
>  break;
>  }
>  
> -if (grab)
> -DeliverGrabbedEvent((InternalEvent *) event, device,
> -deactivateDeviceGrab);
> -else if (device->focus && !IsPointerEvent(ev))
> -DeliverFocusedEvent(device, (InternalEvent *) event,
> -GetSpriteWindow(device));
> -else
> -DeliverDeviceEvents(GetSpriteWindow(device), (InternalEvent *) event,
> -NullGrab, NullWindow, device);
> +/* Don't deliver focus events (e.g. from KeymapNotify when running
> + * nested) to clients. */
> +if (event->source_type != EVENT_SOURCE_FOCUS) {
> +if (grab)
> +DeliverGrabbedEvent((InternalEvent *) event, device,
> +deactivateDeviceGrab);
> +else if (device->focus && !IsPointerEvent(ev))
> +DeliverFocusedEvent(device, (InternalEvent *) event,
> +GetSpriteWindow(device));
> +else
> +DeliverDeviceEvents(GetSpriteWindow(device), (InternalEvent *) 
> event,
> +NullGrab, NullWindow, device);
> +}
>  
>  if (deactivateDeviceGrab == TRUE) {
>  (*device->deviceGrab.DeactivateGrab) (device);
> diff --git a/dix/getevents.c b/dix/getevents.c
> index 4d06818..0d87453 100644
> --- a/dix/getevents.c
> +++ b/dix/getevents.c
> @@ -1101,9 +1101,12 @@ GetKeyboardEvents(InternalEvent *events, DeviceIntPtr 
> pDev, int type,
>  }
>  #endif
>  
> -if (type == KeymapNotify) {
> +if (type == EnterNotify) {
>  source_type = EVENT_SOURCE_FOCUS;
>  type = KeyPress;
> +} else if (type == LeaveNotify) {
> +source_type = EVENT_SOURCE_FOCUS;
> +type = KeyRelease;
>  }
>  
>  /* refuse events from disabled devices */
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index d6eadad..5671b50 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -655,7 +655,7 @@ keyboard_handle_enter(void *data, struct wl_keyboard 
> *keyboard,
>  
>  wl_array_copy(_seat->keys, keys);
>  wl_array_for_each(k, _seat->keys)
> -QueueKeyboardEvents(xwl_seat->keyboard, KeymapNotify, *k + 8);
> +QueueKeyboardEvents(xwl_seat->keyboard, EnterNotify, *k + 8);
>  }
>  
>  static void
> @@ -667,12 +667,8 @@ keyboard_handle_leave(void *data, struct wl_keyboard 
> *keyboard,
>  
>  xwl_seat->xwl_screen->serial = serial;
>  
> -/* Unlike keymap_handle_enter above, this time we _do_ want to trigger
> - * full release, as we don't know how long we'll be out of focus for.
> - * Notify clients that the keys have been released, disable autorepeat,
> - * etc. */
>  wl_array_for_each(k, _seat->keys)
> -QueueKeyboardEvents(xwl_seat->keyboard, KeyRelease, *k + 8);
> +QueueKeyboardEvents(xwl_seat->keyboard, LeaveNotify, *k + 8);
>  
>  xwl_seat->keyboard_focus = NULL;
>  }
> -- 
> 2.9.3
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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 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). sure.
>>> 3fps if it's 16bpp. if the app uses xrender and pixmaps and uploads
>>> all data first this can improve, but clients are more and more
>>> moving away from that model.
>>>