locked
RDP Server Fast Path Update for 32 bpp cursors RRS feed

  • Question

  • I have a question about handling RDP server pointer update PDUs. It appears that under certain conditions RDP for Hyper-V virtual machine sends FASTPATH_UPDATETYPE_POINTER packets with ‘truncated’ 32bpp cursors, for example 32x30 instead of 32x32. All other cursor updates with exception of 32bpp from certain virtual machines seem to have proper 32x32 xor and and mask bitmaps. I’m observing it with a custom client that doesn’t advertise TS_ORDER_CAPABILITYSET (but does set TS_POINTER_CAPABILITYSET and TS_LARGE_POINTER_CAPABILITYSET). At the same time it seems that Microsoft remote desktop client (mstscax.dll) manages to receive 32bpp cursors of a proper size from the virtual machine console. What should be set / sent in the connection sequence in order to overcome this problem?

    Thanks.

     

    Thursday, February 17, 2011 12:51 PM

Answers

  • Follow-up to forum…

     

    In addition to setting TS_LARGE_POINTER_CAPABILITYSET with largePointerSupportFlags = TS_LARGE_POINTER_CAPABILITY_FLAG_96x96, you must also add support for TS_MULTIFRAGMENTUPDATE_CAPABILITYSET with a sufficient MaxRequestSize (see below).  We are updating [MS-RDPBCGR] to document Large Pointer support’s dependency on TS_MULTIFRAGMENTUPDATE_CAPABILITYSET.  These optional MS-RDPBCGR capabilities are mandatory in Remote FX and documented at [MS-RDPRFX] 2.1 Transport as the first two bullet points:

     

    -- The client MUST send the Multifragment Update Capability Set ([MS-RDPBCGR], section 2.2.7.2.6). The MaxRequestSize field in the client-to-server Multifragment Update Capability Set MUST be set to a value greater than or equal to the value in the MaxRequestSize field of the server-to-client Multifragment Update Capability Set. The client-to-server Multifragment Update Capability Set is transported in the Confirm Active PDU as specified in [MS-RDPBCGR] section 2.2.1.13.2, and the server-to-client Multifragment Update Capability Set is transported in the Demand Active PDU as specified in [MS-RDPBCGR] section 2.2.1.13.1.

     

    -- The client MUST send the Large Pointer Capability Set ([MS-RDPBCGR] section 2.2.7.2.7), and the LARGE_POINTER_FLAG_96x96 (0x00000001) MUST be present in the largePointerSupportFlags field.

     

    If Large Pointer support is not enabled, then the server will limit itself to sending cursors that are no larger than 32x32, but it can send smaller cursors.  In your scenario, the server is prepared to send you a 41x39 pointer, but doesn’t believe that you have Large Pointer capabilities.  So, it transforms the cursor into a size that you can accept.  It takes the longest axis (41) and scaled it to fit 32.  It then takes the smaller axis and scales it by (roughly) the same ratio, 30.  This results in the 32x30 pointer you observe.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Monday, April 18, 2011 8:05 PM

All replies

  • Hi,

    Thanks for your question regarding the RDP server path update PDU. One of our engineers will follow up with you soon.

    Thanks,

    Edgar

     

    Thursday, February 17, 2011 3:51 PM
  • Hi, VTTC,

     

    I am researching this for you.

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, February 18, 2011 5:22 PM
  • Thanks. A little bit more context: it seems that in some cases the guest, for example Windows 7, sends ‘truncated’, i.e. 32x30 32bpp cursors only from logon desktop corresponding to the virtual machine console. It starts sending 32x32 32bpp cursors after that.  Also, it seems that mstscax.dll receives 41x39 and / xor mask bitmaps in a corresponding server pointer update when I receive 32x30 cursor…

    Friday, February 18, 2011 5:59 PM
  • Thank you for the extra information.

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Monday, February 21, 2011 5:38 PM
  • VTTC,

     

    Can you contact me directly by sending mail to "dochelp (at) microsoft (dot) com"?

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Saturday, February 26, 2011 1:46 AM
  • Follow-up to forum…

     

    In addition to setting TS_LARGE_POINTER_CAPABILITYSET with largePointerSupportFlags = TS_LARGE_POINTER_CAPABILITY_FLAG_96x96, you must also add support for TS_MULTIFRAGMENTUPDATE_CAPABILITYSET with a sufficient MaxRequestSize (see below).  We are updating [MS-RDPBCGR] to document Large Pointer support’s dependency on TS_MULTIFRAGMENTUPDATE_CAPABILITYSET.  These optional MS-RDPBCGR capabilities are mandatory in Remote FX and documented at [MS-RDPRFX] 2.1 Transport as the first two bullet points:

     

    -- The client MUST send the Multifragment Update Capability Set ([MS-RDPBCGR], section 2.2.7.2.6). The MaxRequestSize field in the client-to-server Multifragment Update Capability Set MUST be set to a value greater than or equal to the value in the MaxRequestSize field of the server-to-client Multifragment Update Capability Set. The client-to-server Multifragment Update Capability Set is transported in the Confirm Active PDU as specified in [MS-RDPBCGR] section 2.2.1.13.2, and the server-to-client Multifragment Update Capability Set is transported in the Demand Active PDU as specified in [MS-RDPBCGR] section 2.2.1.13.1.

     

    -- The client MUST send the Large Pointer Capability Set ([MS-RDPBCGR] section 2.2.7.2.7), and the LARGE_POINTER_FLAG_96x96 (0x00000001) MUST be present in the largePointerSupportFlags field.

     

    If Large Pointer support is not enabled, then the server will limit itself to sending cursors that are no larger than 32x32, but it can send smaller cursors.  In your scenario, the server is prepared to send you a 41x39 pointer, but doesn’t believe that you have Large Pointer capabilities.  So, it transforms the cursor into a size that you can accept.  It takes the longest axis (41) and scaled it to fit 32.  It then takes the smaller axis and scales it by (roughly) the same ratio, 30.  This results in the 32x30 pointer you observe.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Monday, April 18, 2011 8:05 PM