Re: Wayland/weston, Qt and RDP connection...

[Pekka Paalanen]

On Sat, 14 Jan 2023 11:58:37 +0200
Marius Vlad  wrote:

> On Fri, Jan 13, 2023 at 08:07:07PM +, Matti Ristimäki wrote:
> > Hi,  
> Hi,
> > 
> > 
> > 
> > Thanks for the reply!
> > 
> > 
> > 
> > Jep, this might be the reason...
> >   
> > > --modules=systemd-notify.so --modules=screen.share.so  
> > 
> > This might be a long shot but it is screen-share.so (hyphen).

Hi,

this typo would stop Weston from starting, and Weston would clearly say
in its log why. The Weston log output is always important to look at. If
the compositor doesn't start, also applications will fail to start with
"Failed to create wl_display" or other such error.

If you use Weston's --log option, check the file since Weston won't
print its log to the standard output. I might recommend to not use
--log, and let the systemd service unit forward the stdout and stderr
into the journal instead (which it does by default).

> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: EGL: Warning: No default display 
> support on wayland

That means that the application is not checking whether connecting to
a Wayland compositor worked or not. This is an application bug, but
it is just secondary fallout from the primary failure. Quite likely
the application will also crash (segfault).

The reason is that EGL_DEFAULT_DISPLAY is equal to NULL, so I infer
that the application code does not verify that the wl_display is not
NULL before using it.

EGL_DEFAULT_DISPLAY cannot work with Wayland by design.

> > We did try the RDP-weston -session this way too...
> > 
> > 1.
> > 
> > Running RDP-weston -session manually via terminal and after that forcing 
> > weston-smoke to the RDP-weston -session.
> > 
> > 
> > 
> > First weston rdp-backend command via terminal. Notice, that here the 
> > "--modules=screen-share.so" is written correctly: (And after that 
> > WAYLAND_DISPLAY=wayland-0 is running...)
> > 
> > 
> > 
> > weston --backend=rdp-backend.so --modules=screen-share.so 
> > --rdp-tls-cert=/data/etc/ssh/tls.crt --rdp-tls-key=/data/etc/ssh/tls.key  
> Just noticed, you already start weston with the RDP backend *and* with
> the screen-share module. Is that on purpose?

I suspect that is not intended. Having both rdp-backend and
screen-share in the same Weston instance has no use.


> The screen-share module starts a weston instance with the RDP backend
> (assuming you have start-on-startup in the ini file) which you connect
> to.
> 
> So for instance, if you have the following in your ini file:
> 
> [core]
> modules=screen-share.so
> 
> [screen-share]
> command=/path/to/weston --backend=rdp-backend.so --shell=fullscreen-shell.so 
> --no-clients-resize --rdp-tls-key=rdp/tls.key --rdp-tls-cert=rdp/tls.crt 
> --no-config
> start-on-startup=true
> 
> Then you run it like:
> 
> $ /path/to/weston --config /path/to/weston.ini
> 
> It would automatically start *another* weston instance on the machine to 
> connect to. Weston then chooses up, its own a back-end to use locally 
> (for instance the DRM back-end), but also creates another weston instance
> with the RDP back-end (which is being done by the screen-share module).

This is the right idea.

One shall never start the "second" Weston if screen sharing is desired,
only the screen-share plugin in the "first" Weston can do that.

> So, when the second RDP instance is started by screen-share.so it won't
> really do anything as it won't be able to do a socket bind (being an already
> RDP server instance on that port).
> 
> Do you have a display/an output on that local device, or is it without
> any outputs graphic devices?
> 
> Can you provide a full weston log when this happens?

That would be interesting.

Matti, it could be beneficial to build the set-up in steps:

1. No screen-share, no Qt app. Just Weston with its local backend (DRM
   quite likely) and a demo app, e.g. weston-simple-egl (shows a
   spinning triangle in OpenGL ES 2).

2. Add screen-share, but no Qt app. Make sure both local and RDP
   outputs look good with a demo app.

3. Add the Qt app.

If you stop at the first point where you encounter problems, it is
easier to ask and answer.

You have already shown that a stand-alone (non-screen-sharing) RDP
Weston instance works fine with your weston-smoke experiment.

Your Qt app segfaults in the stand-alone RDP Weston instance case. We
have no idea why that would be, when weston-smoke works. If it is
because the app requires hardware accelerated OpenGL (or you use a
proprietary EGL implementation), then it might still work with the
DRM-backend. This is because the RDP-backend does not yet support
hardware accelerated OpenGL or Vulkan apps. Normally apps will just
fall back to Mesa's software renderer, but maybe your app needs
something extra or maybe you are not using Mesa as your EGL etc.
implementation.

A full Weston log would answer many questions.

Proprietary graphics driver stacks tend to be hard to work with,
because obviously we cannot fix them, and they often work only in very
narrow circumstanc

wl_fixed_to_double() function only correct when fixed value is greater than zero

[程安絮]

In file main.go is my implementation of FixedToFloat64 vs wl_fixed_to_double, 
the comments can help you to understand my codes.
Since event wl_touch::orientation's orientation arg is fixed value and can be 
negative, I think this bug is not acceptable.
Besides, I don't understand how wl_fixed_to_double works, can anyone illustrate 
that for me? 

程安絮
package main

/*
double wl_fixed_to_double (unsigned int fix){
	union di {
		double d;
		long i;
	};

	union di u;

	u.i = ((1023L + 44L) << 52) + (1L << 51) + fix;

	return u.d - (3L << 43);
}
*/
import "C"
import (
	. "fmt"
	"unsafe"
)

func main() {
	var i uint64
	var n byte
	for i = 0; i < 0x1; i++ {
		fMy := MyFixedToFloat64(uint32(i))

		fWl := float64( C.wl_fixed_to_double( C.uint(i) ) )

		if fMy != fWl {
			Printf("i: %X\nfMy: %x\nfWl: %x\n", i, fMy, fWl)
			n++
			if n==5{break}
		}
	}

} //main

func MyFixedToFloat64(fix uint32) float64 {


	// fixed value have 1 sign bit and 31 value bits
	// decimal point between bit9 and bit8(right to left index order, start at 1)

	// get sign bit
	var sign uint64 = uint64( fix&0x8000 )<<32

	// shift out 1 sign bit, pad 1 value bit of `0` on right side, value bits increase to 32
	// decimal point and value bits move together(1bit left), don't change the value;
	// decimal point between bit10 and bit9
	fixValue:=fix<<1

	// if value is zero
	// then return float64 value should be `+0` or `-0`, depends on the sign bit
	if fixValue == 0 {
		// wayland use "Native Byteorder", so no need to worry about byte-endian
		// just use pointer convertion to convert bits to float64 value
		return *(*float64)(unsafe.Pointer(&sign) )
	}


	// shift out all successive `0`s on the left side and save number of zeros shifted out in `n0`
	// the most left `1` will be the hidden bit of Fraction, should be shifted out too
	// shift out n0 bits of `0` and 1 bit of `1` on left, pad in n0+1 bits of `0` on the right, so number of value bits is still 32
	// decimal point and value bits move together(n0+1bits left), don't change the value;
	// decimal point between bit(n0+1+10) and bit(n0+1+9) i.e bit(n0+11) and bit(n0+10)
	var n0 uint64
	for {
		if fixValue&0x8000 != 0 {
			fixValue <<=1
			break
		}
		fixValue <<= 1
		n0++
	} //for

	// float64 have 52 Fraction bits, fixValue only have 32 bits
	// so fixValue should be convert to uint64 and shift left 20 bits(pad 20bits of `0` on the right side)
	// decimal point and value bits move together(20bits left), don't change the value;
	// decimal point between bit(20+n0+11) and bit(20+n0+10) i.e bit(31+n0) and bit(30+n0)
	var frac uint64 = uint64(fixValue) << 20

	// float64's decimal point between bit53 and bit 52
	// so float64's decimal point should move 52-(30+n0)bits right i.e (22-n0)bits right
	// move decimal point right equals to increase exponent, so exponent should increase by 22-n0
	// float64's exponent Biased up by 1023, so exponent should be 1023+22-n0 i.e 1045-n0
	// shift left 52bits put exponent at the correct place
	var exp uint64 = (1045 - n0) << 52

	// `or` sign, exponent and fraction together, get the float64bits
	fBits := sign | exp | frac

	// pointer convert float64bits to float64 value
	return *(*float64)(unsafe.Pointer(&fBits))
} // func