Re: [Interest] BLE : Bonding and ble security

[Simon FEUTRIER]

Kai,

Thank you for your message! I tried and it is well recognized when building
but seems to have no effect ( for example qtbluetooth-config.pri file is
not changed ).
I tried the same syntaxe that you gave me with native-win32-bluetooth and
this one works perfectly. I have no idea why ^^.

Regards,

Simon Feutrier


Le ven. 21 août 2020 à 16:43, Kai Köhne  a écrit :

> Hi,
>
> > Von: Interest  Im Auftrag von Simon
> FEUTRIER
> > Betreff: Re: [Interest] BLE : Bonding and ble security
> >
> > I'm trying to use "winrt_btle_no_pairing" with QT_CONFIG(feature) to
> change this
> > default behaviour. But I swear I'm trying for 2 hours and I cannot
> achieve it. I don't see > where / how I can put this with Qt Creator.
>
> winrt_btle_no_pairing is a configure option that you have to set before
> building Qt (and not your application).
>
> If you do a top-level build of Qt, you can pass it to configure
>
>   configure -feature-winrt_btle_no_pairing
>
> if you do a build of just qtconnectivity, the syntax is
>
>   qmake -- -feature-winrt_btle_no_pairing
>
>
> Hope this helps,
>
> Kai
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] BLE : Bonding and ble security

[Kai Köhne]

Hi,

> Von: Interest  Im Auftrag von Simon FEUTRIER
> Betreff: Re: [Interest] BLE : Bonding and ble security
>
> I'm trying to use "winrt_btle_no_pairing" with QT_CONFIG(feature) to change 
> this 
> default behaviour. But I swear I'm trying for 2 hours and I cannot achieve 
> it. I don't see > where / how I can put this with Qt Creator.

winrt_btle_no_pairing is a configure option that you have to set before 
building Qt (and not your application).

If you do a top-level build of Qt, you can pass it to configure

  configure -feature-winrt_btle_no_pairing

if you do a build of just qtconnectivity, the syntax is

  qmake -- -feature-winrt_btle_no_pairing


Hope this helps,

Kai
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] BLE : Bonding and ble security

[Simon FEUTRIER]

Hi,

I'm digging into my problem and keep updating the bug report
https://bugreports.qt.io/browse/QTBUG-86095. I was wondering if it is not
related to the fact that the device is not paired (since last release of Qt
devices are not necessarily paired).
I'm trying to use "winrt_btle_no_pairing" with QT_CONFIG(feature) to change
this default behaviour. But I swear I'm trying for 2 hours and I cannot
achieve it. I don't see where / how I can put this with Qt Creator.
I already looked at the documentation and really find nothing helpful. I
also tried to directly modify some header files directly but nothing is
working and it is very frustrating because it is 1 line...
Do you have any suggestions? Thank you..

Best regards,

Simon Feutrier


Le mar. 18 août 2020 à 15:29, Simon FEUTRIER  a
écrit :

> Hi Jérôme,
>
> I did it and it is working with this Windows app. Thus, it seems to be Qt
> related. I have specified it in the bug report.
> Thank you for your help.
>
> Regards,
>
> Simon Feutrier
>
>
> Le mar. 18 août 2020 à 15:07, Jérôme Godbout  a
> écrit :
>
>> Hi,
>>
>> Just to put aside the Windows, you could try to connect using Bluetooth
>> LE Explorer application:
>> https://www.microsoft.com/en-us/p/bluetooth-le-explorer/9n0ztkf1qd98
>>
>> It could tell if the Window BLE can perform the connection properly on
>> his own.
>>
>>
>>
>> Jerome
>>
>>
>>
>> *From:* Simon FEUTRIER 
>> *Sent:* August 18, 2020 4:09 AM
>> *To:* Alex Blasche 
>> *Cc:* Jérôme Godbout ; interest@qt-project.org
>> *Subject:* Re: [Interest] BLE : Bonding and ble security
>>
>>
>>
>> If you are interested to follow this problem, there is now also a bug
>> ticket here :  https://bugreports.qt.io/browse/QTBUG-86095
>>
>>
>> Regards,
>>
>>
>>
>> Simon Feutrier
>>
>>
>>
>>
>>
>> Le mar. 18 août 2020 à 09:15, Simon FEUTRIER  a
>> écrit :
>>
>> Hi !
>>
>>
>>
>> Jérôme, yes it is well secured, very well, even I cannot communicate :D.
>>
>> For your questions, Qt is supported on Windows, Bluetooth LE as well.
>> About the security I am not sure I did not receive a clear reply to that
>> question but it seems yes.
>>
>> My ble device and my Windows are recent enough yes !
>>
>> Currently in my ble device I am just activating "Just Work" security. And
>> on Windows...I just cannot set the security level, so... ^^
>>
>>
>>
>> Alex, I will create an issue then.
>>
>>
>>
>> Thank you for your help.
>>
>>
>>
>> Cordialement,
>>
>>
>>
>> Simon Feutrier - Ingénieur systèmes embarqués
>>
>>
>>
>> BLUEGRioT
>>
>>
>>
>>
>>
>> Le lun. 17 août 2020 à 22:13, Alex Blasche  a
>> écrit :
>>
>>
>>
>> 
>> From: Interest  on behalf of Simon
>> FEUTRIER 
>> Sent: Monday, 17 August 2020 16:31
>> To: Jérôme Godbout
>>
>> >Alex, thank you for your quick reply. I just tried with the pre-release
>> 5.15.1 and this is the same behavior.
>>
>> Since you revealed that you are on Windows only, the patch I sent makes
>> no sense. It is an Android only patch. This needs a proper bug report now.
>>
>> --
>> Alex___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
>>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop

[Daljit Singh]

There is another possibility. Keep vsync but add a frame delay. That is,
if you know your application can finish each frame in less than, say,
5ms, then you delay the start of each frame loop by 1000/Hz - 5
milliseconds. For 60Hz that means sleeping for 11.6ms after rendering
the last frame. The render loop then reads input and renders the next
frame in the remaining 5ms, giving you a latency of 5ms instead of 16.7.

Thanks Nikos for your reply. I am quite new to the world of computer graphics 
so your thoughts were really helpful. Following your ideas, I was noticeably 
able to improve the latency in my application! The average render time for each 
frame (when not scrolling) is about 1-2 ms (I rudimentally tested this using 
QElapsedTimer in debug mode), since I cache what has previously been drawn in 
an FBO. What I did then is schedule a timer with an interval of 15ms (my screen 
refresh rate is 60hz) that get triggered after calling QQuickItem::update() and 
when the new input events from the pen come in I put them in a queue until the 
timer has stopped running (so effective calling the next update() slot at t > 
15ms). This little hack helped quite a bit and it's very convenient since I am 
able to turn it off at any point I need, so when the latency is not critical 
(e.g. when scrolling my canvas) I switch it off.
I made some rudimental test videos using my phone (60 fps 0.5 speed) which 
shows the improvements: Normal latency vs Improved 
latency. Of course, disabling vsync still gives 
better results.

Just as an extra data point: have you tried driving the Qt Quick render
loop manually, using QQuickRenderControl?
Yes Giuseppe, you're right I forgot to mention that option. I am not too 
familiar with this class so I need to study it before attempting this. However, 
I would like to avoid this since it would essentially involve creating your own 
threaded renderer and it would require significant time to build and maintain a 
solution that has feature parity with the default solution provided by Qt 
(although from the example in the documentation it doesn't seem to be too bad).



From: Interest  on behalf of Nikos Chantziaras 

Sent: 21 August 2020 03:10
To: interest@qt-project.org 
Subject: Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop

On 19/08/2020 18:57, Daljit Singh wrote:
> - the vsync issue is commonly known in competitive gaming where input
> lag is quite important, one way to solve this would to limit the
> framerate of the application to be slightly lower than the display
> refresh rate (this
> https://medium.com/@petrakeas/vsync-with-low-input-lag-50ms-lower-2437118bfa5
> provides more details). However, Qt provides no way to limit the
> framerate of an app.

A frame rate cap will result in a cyclic latency graph. On *average* the
latency will be reduced, but individual frame will oscilate between 0
and 16.7ms of latency over time.

So this actually works for bringing down average latency when playing
games, but the variable latency effect might not be wanted in a
professional application.


> - the possibility of dynamically turning off V-Sync at runtime would
> allow an app to operate in "low-latency" mode when required. Currently
> this is not possible in Qt, as the QSurfaceFormat::setSwapInterval needs
> to be called before the QML scene is created.
>
> - make the threaded renderloop not rely on Vsync throttling so low
> latency and multithreaded rendering is possible, this was what I wanted
> to know in my previous reply. There seem to be changes to the render
> loop in Qt 6, but I am not sure if this has been implemented.

There is another possibility. Keep vsync but add a frame delay. That is,
if you know your application can finish each frame in less than, say,
5ms, then you delay the start of each frame loop by 1000/Hz - 5
milliseconds. For 60Hz that means sleeping for 11.6ms after rendering
the last frame. The render loop then reads input and renders the next
frame in the remaining 5ms, giving you a latency of 5ms instead of 16.7.

If you miss the target time though, then that frame will need to wait
for the next vblank, resulting in a 33.3ms frame time. Or you disable
vsync for just that frame, which will give you a tear.

However, there's other factors at play here as well. The GPU driver
usually does not immediately send out each frame immediately to the
screen when it's presented. Furthermore, since frame preparation (CPU)
and frame rendering (GPU) are asynchronous in today's graphics APIs, you
get several prepared frames queued up for rendering. This is the biggest
contributor to latency today, not the 16.7ms frame latency of 60Hz
double buffer vsync. That's why disabling vsync in games for example
doesn't give you a 16.7ms reduction, it gives you more like 50ms.

So to get as low a latency as possible while avoiding the variable
latency issue of frame rate 

Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop

[Giuseppe D'Angelo via Interest]

Il 19/08/20 17:57, Daljit Singh ha scritto:

Now I think there might be some ways this could be solved:


Just as an extra data point: have you tried driving the Qt Quick render 
loop manually, using QQuickRenderControl?


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest