Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial rfx progressive integration #2879

Conversation

Nexarian
Copy link
Contributor

  • Mostly base functions and utilities necessary to enable RFX Progressive
  • Add more EGFX work.
  • Update encoder.
  • Does not yet include caps determination to enable RFX progressive (yet).

if (client_info->mcs_connection_type != CONNECTION_TYPE_LAN)
{
return 0;
if ((mm->egfx_flags & 3) == 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is 3 come from?

Copy link
Contributor Author

@Nexarian Nexarian Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know I was wondering that myself (Most of this is code's lineage comes from Jay's original egfx branch that was started many years ago).

I think it's this: In this simplified version of GFX, this flag can only ever be 1 (For H264) or 2 (For Progressive RFX). Anding with 3 means "It is neither 1 nor 2":

0b00 & 3 = 0
0b01 & 3 = 1
0b10 & 3 = 2
0b11 & 3 = 3

So basically, if it's not a LAN connection, and it's not EGFX, drop the connection because the only other use for the encoder is "non-progressive RFX" which requires LAN per the spec.

There's probably a clearer way to write this. I think egfx_flags needs to become an enum, too. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. Either enum or define as macro would be clearer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated!

@Nexarian Nexarian force-pushed the add_egfx_multimon_common branch 3 times, most recently from 8d128ca to 80e8268 Compare December 19, 2023 05:16
@@ -2133,7 +2133,15 @@ xrdp_sec_process_mcs_data_CS_CORE(struct xrdp_sec *self, struct stream *s)
{
client_info->bpp = 32;
}

if (earlyCapabilityFlags & 0x100) /* RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@metalefty
Copy link
Member

Logic looks good to me. Some trivial thoughts.


if (earlyCapabilityFlags & 0x100) /* RNS_UD_CS_SUPPORT_DYNVC_GFX_PROTOCOL */
{
LOG_DEVEL(LOG_LEVEL_INFO, "client supports gfx");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be LOG instead of LOG_DEVEL.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Do you think the "client DOES NOT support gfx" message should also be a LOG?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either is fine. Let's leave it as-is now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... Should I merge this then?

- Mostly base functions and utilities necessary to enable RFX
  Progressive
- Add more EGFX work & mode flags.
- Update encoder.
- Does not yet include caps determination to enable RFX progressive
  (yet).
- Update protocol constants
@metalefty
Copy link
Member

@Nexarian I have created gfx_mainline_merge_work branch. Let's merge into the branch now. After everything's done, let's merge gfx_mainline_merge_work into devel.

@metalefty metalefty changed the base branch from devel to gfx_mainline_merge_work December 20, 2023 05:39
Copy link
Member

@matt335672 matt335672 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely worth getting this into its own branch

@@ -71,6 +71,6 @@ libcommon_la_SOURCES = \
$(PIXMAN_SOURCES)

libcommon_la_LIBADD = \
-lpthread \
-lpthread -lrt \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is needed - it seems to build OK without it. Am I missing a compile option?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, again, future use. Trying to get in base/fundamental changes that I know we will need in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with that. Thanks for the clarification.

The reason I raised it was there's probably a better way to add this with autotools. I'll investigate further when we've got more dependencies to play with.

{
/* gfx session but have not recieved caps advertise yet,
set flag so we will connect to backend later */
self->mm->gfx_delay_autologin = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flag appears to be set but not used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. It's intended for future use, just like the xrdp_egfx.c and xrdp_egfx.h files. It WILL be used once GFX is turned on.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@Nexarian
Copy link
Contributor Author

@Nexarian I have created gfx_mainline_merge_work branch. Let's merge into the branch now. After everything's done, let's merge gfx_mainline_merge_work into devel.

Hmm, I had a slightly different approach. I was thinking that we slowly merge the pieces that we're sure we need into devel in smaller chunks like this. In this way it gives us an opportunity to tune/review smaller pieces over time. We can put the actual enabling of RFX Progressive/GFX under a build flag and call it experimental until we decide to officially release it. It also avoids the entirety of the mainline_merge problem where it became something of a second-devel/release that many were unofficially using.

However, I'm open to doing it this way as well. Given that there are unfinished "for future use" portions in this PR, I'll merge into gfx_mainline_merge_work

@Nexarian Nexarian merged commit 02d329e into neutrinolabs:gfx_mainline_merge_work Dec 20, 2023
13 checks passed
@Nexarian Nexarian deleted the add_egfx_multimon_common branch December 20, 2023 14:58
@metalefty
Copy link
Member

It also avoids the entirety of the mainline_merge problem where it became something of a second-devel/release that many were unofficially using.

I think it is not a big problem now because gfx_mainline_merge_work will be merged into devel in a month and we will focus on GFX for a while. So other developments are suspended and not so many other pull requests will be merged into devel.

@matt335672
Copy link
Member

I'm happy with pausing other developments for now. #2745 is probably the biggest outstanding change I've got and that can wait.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants