Logging to a file by default isn't common.
Use a more verbose and developer-friendly format in this case.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
mstsc does not display bitmap update, for some reason. Using
SetSurfaceBits instead solves it, and is required for more advanced codecs.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Those flags are set both by client and server. Even if the server
doesn't send those commands yet, this should be supported by most
clients.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Use u16 since that's the limit for resolution and bitmap data.
Use non-zero types for width & height, to avoid various issues, such as
division by zero.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The fragment index is not correctly updated, staying at 0, making
invalid series of First/First/..Last.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This allows to simplify some user code, and let us introduce a
"protocol_version" field in the next patch without having to explicitly
set its value but rely on the default instead.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Hiding the lifetimes is making the code less obvious.
That’s not a problem for types that I know about intimately such as
`ReadCursor` or `WriteCursor`, but I actually found myself surprised
more than once when reading code I didn’t authored, discovering later
there was in fact a hidden lifetime parameter.
I expect this problem to be worse for someone not familiar with
our codebase.
I understand this lint is "allow" by default because in some cases
it leads to writing unergonomic ugly code when a type has many generic
lifetimes parameters:
```
TyCtxt<'_, '_, '_>
```
However we _never_ work with more than one generic lifetime parameter in
IronRDP codebase, so it seems to me that the tradeoff towards clarity is
worth it, in our case.
