Re: Wayland/weston, Qt and RDP connection...
On Mon, Jan 16, 2023 at 02:25:25PM +, Matti Ristimäki wrote: > Hi, Hi, > > > > Ok, this might be the reason… > > 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. > Right, the proprietary driver can't/won't fallback to a software renderer, or it doesn't have a pipeline that can do that. Also, you could probably replicate this without the RDP backend at all, by just start weston with --use-pixman argument and attempt to start any client that wants to perform 3D/hardware acceleration and would probably die out the same. > > > > > Testing weston-simple-egl with RDP and HDMI-display > > > > > > "Force driving" weston-simple-egl to RDP-weston session: > (WAYLAND_DISPLAY=wayland-1) > > > > Command: > > > > WAYLAND_DISPLAY=wayland-1 weston-simple-egl > > has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage > > Segmentation fault > > > > Logging: > > > > root@sm2s-imx8mp:~# journalctl -f > > -- Journal begins at Mon 2023-01-16 09:50:23 CET. -- > > Jan 16 11:47:32 sm2s-imx8mp audit[1569]: ANOM_ABEND auid=0 uid=0 gid=0 ses=5 > pid=1569 comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1 > > Jan 16 11:47:32 sm2s-imx8mp kernel: audit: type=1701 > audit(1673866052.888:25): auid=0 uid=0 gid=0 ses=5 pid=1569 > comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1 > > > > Result: > > > > Doesn't work. > > > > > > And similar error appears, when I’m trying to drive “Qt” application on > RDP-weston: > > > > Jan 16 13:51:55 sm2s-imx8mp audit[2027]: ANOM_ABEND auid=0 uid=0 gid=0 ses=5 > pid=2027 comm="QSGRenderThread" exe="/opt/cpx/cpx" sig=11 res=1 > > Jan 16 13:51:55 sm2s-imx8mp kernel: audit: type=1701 > audit(1673873515.594:33): auid=0 uid=0 gid=0 ses=5 pid=2027 > comm="QSGRenderThread" exe="/opt/cpx/cpx" sig=11 res=1 > > > > > > > > > > > > > > > > "Force driving" weston-simple-egl to a HDMI display > (WAYLAND_DISPLAY=wayland-0) > > > > Command: > > > > WAYLAND_DISPLAY=wayland-0 weston-simple-egl > > > > Logging: > > > > root@sm2s-imx8mp:/opt/cpx# WAYLAND_DISPLAY=wayland-0 weston-simple-egl > > has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage > > 304 frames in 5 seconds: 60.79 fps > > 302 frames in 5 seconds: 60.42 fps > > 302 frames in 5 seconds: 60.42 fps > > 302 frames in 5 seconds: 60.42 fps > > 302 frames in 5 seconds: 60.42 fps > > > > > > Result: > > > > Works fine, animation runs smoothly. > > > > [cid:image001.png@01D929AF.41CA1A80] > > > > > > > > > > > > BR, > > > > -Matti > > > > > > > > > > -Original Message- > From: Pekka Paalanen > Sent: maanantai 16. tammikuuta 2023 11.40 > To: Matti Ristimäki > Cc: Marius Vlad ; > wayland-devel@lists.freedesktop.org > Subject: Re: Wayland/weston, Qt and RDP connection... > > > > On Sat, 14 Jan 2023 11:58:37 +0200 > > Marius Vlad mailto:marius.v...@collabora.com>> > 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 appl
Re: Wayland/weston, Qt and RDP connection...
On Mon, 16 Jan 2023 14:25:25 + Matti Ristimäki wrote: > Hi, > > > > Ok, this might be the reason… > > 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. > > > > > > Testing weston-simple-egl with RDP and HDMI-display > > > > > > "Force driving" weston-simple-egl to RDP-weston session: > (WAYLAND_DISPLAY=wayland-1) > > > > Command: > > > > WAYLAND_DISPLAY=wayland-1 weston-simple-egl > > has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage > > Segmentation fault > > > > Logging: > > > > root@sm2s-imx8mp:~# journalctl -f > > -- Journal begins at Mon 2023-01-16 09:50:23 CET. -- > > Jan 16 11:47:32 sm2s-imx8mp audit[1569]: ANOM_ABEND auid=0 uid=0 > gid=0 ses=5 pid=1569 comm="weston-simple-e" > exe="/usr/bin/weston-simple-egl" sig=11 res=1 > > Jan 16 11:47:32 sm2s-imx8mp kernel: audit: type=1701 > audit(1673866052.888:25): auid=0 uid=0 gid=0 ses=5 pid=1569 > comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1 > > > > Result: > > > > Doesn't work. Hi, sure, but that's also irrelevant. You will not be running any application on Weston/RDP when you want to use screen-share. You will be running your apps on Weston/DRM, and if they work there, then adding screen-share won't cause them to fail either. Thanks, pq pgpAoDooXfPc_.pgp Description: OpenPGP digital signature
Re: wl_fixed_to_double() function only correct when fixed value is greater than zero
On Mon, 16 Jan 2023 14:43:43 +0800
"程安絮" wrote:
> 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?
>
> 程安絮
Hi,
that wl_fixed_to_double() implementation in C is a far too smart trick
for no other good reason than trying to be fast in a case where speed
is not needed.
The human readable conversion would be:
double wl_fixed_to_double(wl_fixed_t f)
{
return (double)f / 256.0;
}
The trick code seems to be just fine through. I've attached a test
program that iterates through all possible wl_fixed_t values and
ensures the trivial conversion agrees with the trick conversion.
I cannot explain how it works, but it does seem to work.
Thanks,
pq
#include
#include
#include
#include
typedef int32_t wl_fixed_t;
static inline double
wl_fixed_to_double(wl_fixed_t f)
{
union {
double d;
int64_t i;
} u;
u.i = ((1023LL + 44LL) << 52) + (1LL << 51) + f;
return u.d - (3LL << 43);
}
int
main(void)
{
int32_t i = INT32_MIN;
bool stop = false;
do {
wl_fixed_t f = i;
double ref = (double)f / 256.0;
double d = wl_fixed_to_double(f);
if (ref != d)
printf("%10d: %f != %f\n", f, ref, d);
if (i % 1 == 0)
printf("%10d: %f <-> %f\n", f, ref, d);
stop = i == INT32_MAX;
i++;
} while (!stop);
return 0;
}
pgpVl9vtiLtJC.pgp
Description: OpenPGP digital signature
Re: wl_fixed_to_double() function only correct when fixed value is greater than zero
Hi,
The trick is a variant of the well-known integer-to-float conversion
trick you do if you don't have dedicated hardware for it [0].
64-bit floats have a 52-bit significand and a floating exponent.
Wayland's 24.8 fixed point format can be thought of as a 32-bit
significand and a fixed exponent of 8. To convert from one to the
other. It's enough to stuff the 32-bit significand into the 52-bit
field without it overflowing, so that gets you *a* number, but you
need to set up the correct exponent. If you just try stuffing "8" in
the field, it won't work, because of the implicit "1" at the start of
the significand -- this is what ensures our exponent "buckets" are
non-overlapping, distinct ranges. We need to find the floating point
bucket that has the same precision as our input value. The correct
bucket is actually (num_bits_in_significand - num_bits_in_fixed_point)
-- so that's (52 - 8), which is 44. In the floating point format,
exponents are also biased by 1023, so that explains the "(1023 + 44)
<< 52". This is placing the right exponent in the exponent field of
the float.
The extra bit at (1 << 51) is a bias to handle signed values correctly
-- this way, adding a signed value to the float won't take us out of
our bucket.
However, because of that implicit 1, our floats are offset to a
different range. That's easy enough, we just need to subtract out the
start of that range. If you interpret ((1023 + 44) << 52) + (1 << 51)
as a double float, you see it ends up with a value of 0x1800,
which is indeed (3 << 43). There's probably a more direct way to
compute that, but I don't know what it is.
No clue if this helped at all, or just made things more confusing. In
any case, the existing code is correct, but a direct port to another
language might be tricky. If you want a portable method, I'd recommend
what Pekka suggests, which is just (v / 256.0f).
[0] https://cr.yp.to/2005-590/powerpc-cwg.pdf#page=104 , "Convert
32-Bit Unsigned Integer to Floating-Point Code Sequence"
On Tue, Jan 17, 2023 at 7:27 AM Pekka Paalanen wrote:
>
> On Mon, 16 Jan 2023 14:43:43 +0800
> "程安絮" wrote:
>
> > 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?
> >
> > 程安絮
>
> Hi,
>
> that wl_fixed_to_double() implementation in C is a far too smart trick
> for no other good reason than trying to be fast in a case where speed
> is not needed.
>
> The human readable conversion would be:
>
> double wl_fixed_to_double(wl_fixed_t f)
> {
> return (double)f / 256.0;
> }
>
> The trick code seems to be just fine through. I've attached a test
> program that iterates through all possible wl_fixed_t values and
> ensures the trivial conversion agrees with the trick conversion.
>
> I cannot explain how it works, but it does seem to work.
>
>
> Thanks,
> pq
--
Jasper
24.8 fixed to float64/double three ways
In main.go are three ways to convert 24.8 fixed value to float64/double type.
The 3d one is my way which is not efficient but is useful to illustrate how to
convert 24.8 fixed value to float64/double
type.程安絮package main
import (
. "fmt"
"unsafe"
)
func main() {
var u uint64
for u = 0; u < 0x1; u++ {
i:=int32(u)
// first way:
// Most languages (e.g. C/Go) encapsulates "value convertions" from int/uint to float
// These convertion ether use cpu directives or (when cpu don't have such directives) use a well-knonwn way to do the same work.
// The key part is `i` must be a signed integer type, `float64(u)/256` will return a wrong float64 value
// Most developers should use this way unless the language you use don't encapsulates "value convertions" from int/uint to float
// This way is much more readable and easy to understand
fA:=float64(i)/256
// second way:
// This function use variant of a well-known way(mentioned in first way) to "value convert" int to float64
// Like first way, the key part is arg `i` must be a signed integer type
// I don't know how it works but I implemented a clumsy way to do the same work
// Most developers should just use the first way, unless the language you use don't encapsulates "value convertions" from int/uint to float
fB:=WlFixedToFloat64(i)
if fA!=fB{
Printf("i: %X\nfGoSimple: %X\nfGo: %X\n", i, fA, fB)
break
}
// My way:
// My clumsy way to "value convert" 24.8 fixed value to float64 value
fC := MyFixedToFloat64(uint32(i))
if fA!=fC{
Printf("i: %X\nfGoSimple: %X\nfC: %X\n", i, fA, fC)
break
}
}//for
} //main
//
func WlFixedToFloat64(f int32) float64 {
u_i := (1023+44)<<52 + (1 << 51) + int64(f)
u_d := *(*float64)( unsafe.Pointer(&u_i) )
return u_d - (3 << 43)
}
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
// if fixed value is positive
if sign==0{
// if value bits is all `0`, return float64 value 0
if fix==0{return 0}
}else{
// if fixed value is negtive
// convert fix bits from complement form to true form
// then put sign bit to zero
fix=((^fix)+1)&0x7fff
// there is a special case, when all fix value bits is `0`, (^fix)+1 will overflow
// the really true form should be 0x8000
if fix==0{fix=0x8000}
}
// 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+9) and bit(n0+1+8) i.e bit(n0+10) and bit(n0+9)
var n0 uint64
for {
if fix&0x8000 != 0 {
fix <<=1
break
}
fix <<= 1
n0++
} //for
// float64 have 52 Fraction bits, fix only have 32 bits
// so fix 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+10) and bit(20+n0+9) i.e bit(30+n0) and bit(29+n0)
var frac uint64 = uint64(fix) << 20
// float64's decimal point between bit53 and bit 52
// so float64's decimal point should move 52-(29+n0)bits right i.e (23-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+23-n0 i.e 1046-n0
// shift left 52bits put exponent at the correct place
var exp uint64 = (1046 - 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
