text:
WiFi firmware for RPi 3 Model B+ not included in release 2.2.0

Booting release 2.2.0 on RPi 3B+ using WiFi fails with:
Waiting for wlan0... 1.. 2.. 3.. 4.. 5.. 6.. 7.. 8.. 9.. 10.. 11.. 12.. 13.. 14.. FAILED
The kernel doesn't seem to find the WiFi drivers (probably the firmware). I see the following kernel message immediately before the raspberrypi-ua-netinst  comes up:
brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.bin failed with error -2

I switched to booting from Ethernet and - while boot succeeded - the same message was in logs and the Wifi interface was nowhere to be seen. Only after installing the raspbian package "firmware-brcm80211" and manually configuring wpa_supplicant did the Wifi interface appear and connect to my network.
installer-config for failed boot
hostname=ts99

packages=nano,htop,usbutils,libnss-mdns,avahi-utils,apt-utils,psmisc,gcc,wpasupplicant,wireless-tools,raspi-config

dt_overlays="pi3-disable-bt"

ifname=wlan0
wlan_ssid="my_ssid"
wlan_psk="my_passwd"
wlan_country="EE"

A side note - I would really, really like to boot and install my RPi-s en masse (that's why I'm using this fine automated installer, after all) on my desk using Ethernet and subsequently move them to their final location where they'll be using WiFi. This WiFi is not available where I'm doing the installation work. Is that not possible ATM?

Thank you for the quick response - I will be able to test the RC next Monday.

Fix confirmed, thank you. Using RC2 the WiFi on RPi 3B+ works out of the box.
I disconnected Ethernet, ran the installer. Both installer and post-boot normal mode see the WiFi interface and connect to the network I have here (using the same config as above).

Thanks for the feedback (and your email)! I'll merge and release it today evening.

authors: DaStoned FooDeas

repo: FooDeas/raspberrypi-ua-netinst

license: isc


text:
Translation unit name collision

After #341, we now have a potential for name collision between different translation units. Consider two files called a/x.c and b/x.c: if both use statics, then two container types named x<Statics> will be generated.
We should think about resolving this somehow.

I propose to implement the following naming schema for internal types (i.e. then <Statics>).

Introduce the concept of compilation context directory. All the paths will be resolved relative to said directory.
The compilation context by default is determined from the current directory, but should be possible to override via the compiler arguments.

When compiling a translation unit, emit its <Statics> into a name corresponding to the file path relative to the compilation context directory. When processing the file paths, perform the following substitutions:

dot becomes a _: for example, a.c gets compiled as a_c<Statics>,
a directory separator gets mapped to a namespace separator: for example, foo/a.c becomes foo.a_c<Statics>,
real characters \, <, >, and _ have to be escaped with \: for example, a file name f_o_o/a<duh>.c (which is very odd even for a Linux system, I should say) becomes f\_o\_o.a\<duh\>_c<Statics>,
any other characters get translated as-is, even if they are odd. For example, a file name a\b\c| (which is possible to achieve on a Unix system) would generate a type a\\b\\c|<Statics>.

Odd file system configuration cases:

if we have to traverse the parent directory to get to the file from a compilation context, replace that with a special mark <_>. For example, a path ../../foo.c would become <_>.<_>.foo_c<Statics>,
if the path to a file cannot be achieved via the file system (i.e. multi-root file system, such as the Windows one), then just process the full file path according to the rules from the step 2. For example, a path C:\Windows\System32\main.c would emit a file C:.Windows.System32.main_c<Statics>.

Some normal-ish examples:

foo.c → foo_c<Statics>
3rdparty/lib/foobar.c → 3rdparty.lib.foobar_c<Statics>
../3rdparty/foo.c → <_>.3rdparty.foo_c<Statics>

This may or may not serve as the basis for #372, we'll see.
@Fantoom, @kant2002, what do you think?

I have nothing against, except I dislive that we pollute paths in the class names. I thinkinig about having add prefix to generate unique names for paths outside current dir, but that's has their own issues like you have to guess path to translation unit. Maybe we can use attributes in that case.
I was writing this, what if we have plain list of translaiton names which uses just filename + prefix and thats it. We don't really need anything except unique class names. Paths maybe needed right now because we don't emit PDB. And even if it's clashes number of clashes should be relatively low. If we add PDB issue with complex naming would be solved, since we will see then in debugger.
Right now how I understand we will give to Cesium list of all C files and will produce single executable. So Cesium definitely has ability to make sure that all base names for translation units are unique.

@kant2002, do you suggest us to add an option for the user to provide the class names for every translation unit? We could add that as an option, but we'll still have to generate them somehow by default.
Look, one of my concerns is naming stability. Let's imagine that we started autogenerating the names and only "pollute" them if we detect a naming conflict. For example, we'll not pollute these two paths:

src/foo.c → foo<Statics>
src/bar.c → bar<Statics>

But will automatically figure out that we need to resolve a conflict in case of

foo/a.c → foo.a<Statics>
bar/a.c → bar.a<Statics>

So far so good, right?
But then, here's my concern: the name stability.
If implement this kind of smart automation, then that will mean that adding a new translation unit will affect the names of already existing ones, and that's a huge problem for any kind of linkage.
For <Statics>, it won't be a problem, since the names aren't public anyway, so we can do anything: renumber them internally, use a GUID or whatever.
But if we use the same strategy for any kind of public names, then we'll be in trouble: a version of the library compiled with different sources (or on a different platform where the library source files are placed differently) will become binary incompatible with the previous version. That's the thing I'm trying to avoid.

the name stability is good point. I did not consider it. But let's look at this in following way. Public symbols in .NET which you would see is corresponding to the regular linker entries in C. It is not possible to have collisions in linker, so if you take existing app, and we make public just same things which are exposed to linker in C, then we have stable public interface.
I have to think about stable internal namings which is also valuable. IMO it is nice to have and must have, but you may tell me what I'm missing.

source: gharchive/issue

repo: ForNeVeR/Cesium

license: MIT

license_type: permissive

license_source: github-api


text:
stdio: ignore

// input => req,  output => res
var res = spawnSync(command, args, {input: req});

so don't inherit IO from parent process.

Why would we do this?  Using inherit ensures that any errors that occur in the child process get reported to stderr and can be debugged.

source: gharchive/pull-request

authors: ForbesLindesay moyuyc

repo: ForbesLindesay/sync-request

license: mit

license_source: bigquery


text:
Conditional selection without generic base interface

The documentation on Conditional selections with .grab results in this interface:
type QueryResult = (
  | { _id: string; name: "Bulbasaur"; hp: number }
  | { _id: string; name: "Charmander"; attack: number }
  | { _id: string }
)[];

However, I want to end up with this interface, without a generic { _type: string } base interface:
type QueryResult = (
  | { _type: "bulbasaur"; name: string; hp: number }
  | { _type: "charmander"; string; name: string; attack: number }
)[];

Using a query something like this (example code, this doesn't work):
q("*")
  .filter("_type == 'bulbasaur' || _type == 'charmander'")
  .grab(
    {}, // Empty object because I need something here
    {
      "_type == 'bulbasaur'": {
        _type: q.literal("bulbasaur"),
        name: q.string(),
        hp: ["base.HP", q.number()],
      },
      "_type == 'charmander'": {
        _type: q.literal("charmander"),
        name: q.string(,
        attack: ["base.Attack", q.number()],
      },
    }
  );

Is there a way to perform a query in GROQD and end up with a union interface containing only the types I requested? Is there something more appropriate than conditional selections I should be using instead?

Great question! This is fundamentally a short-coming of .grab, but @littlemilkstudio recently added/documented a new .select method that should resolve this! In cases like this, I believe you can swap out the .grab with two arguments, for a .select with just a single argument, and won't have to worry about the pesky empty interface.
If that doesn't resolve this problem for you, let's reopen this issue and discuss further!

It feels a little cleaner to use select here, but I still have a similar issue. If I drop the default I end up with a type similar to this:
type QueryResult = (
  | { _type: "bulbasaur"; name: string; hp: number }
  | { _type: "charmander"; string; name: string; attack: number }
  | Record<string, never>
)[];

If I do include default, e.g. default: { _type: q.literal("unsupported") }, I end up with a type similar to this:
type QueryResult = (
  | { _type: "bulbasaur"; name: string; hp: number }
  | { _type: "charmander"; string; name: string; attack: number }
  | { _type: "unsupported" }
)[];

It is a little clearer at least. Not sure how to improve this. Thanks for looking into this.

Very clever. Using default like that makes a lot of sense. This solves my issue, thanks!
Thanks for the tip on the GROQ tool also.

authors: esseb gksander

repo: FormidableLabs/groqd


text:
Hover input element

I'm using redux-form, Radium and I get an rerender when hovering input element. This makes my form slow. Is there something I have missed? When removing Radium styles no rerender is triggered.
import Radium from 'radium';

let _matchMedia = null;

function ConfiguredRadium(component) {
  return Radium({
    matchMedia: _matchMedia,
    plugins: [
      Radium.Plugins.mergeStyleArray,
      Radium.Plugins.checkProps,
      Radium.Plugins.resolveMediaQueries,
      Radium.Plugins.resolveInteractionStyles,
      Radium.Plugins.prefix,
      Radium.Plugins.checkProps,
    ]
  })(component);
}

ConfiguredRadium.setMatchMedia = (matchMedia) => {
  _matchMedia = matchMedia;
};

export default ConfiguredRadium;

import React, {Component, PropTypes} from 'react';
import {connectReduxForm} from 'redux-form';
import BamConfiguredRadium from '../../../bam-radium-config';

let styles = {
  base : {
        display: 'block',
        width: '100%',
        height: '20px',
        padding: '6px 6px',
        fontSize: '14px',
        lineHeight: '1.42857143',
        outline: '0',
        color: '#555',
        backgroundColor: '#fff',
        backgroundImage: 'none',
        border: '1px solid #ccc',
        marginBottom : '4px',
        borderRadius: '4px',
        WebkitBoxShadow: 'inset 0 1px 1px rgba(0, 0, 0, .075)',
        boxShadow: 'inset 0 1px 1px rgba(0, 0, 0, .075)',
        WebkitTransition: 'border-color ease-in-out .15s, -webkit-box-shadow ease-in-out .15s',
        transition: 'border-color ease-in-out .15s, box-shadow ease-in-out .15s',
        ':focus' : {
             border: '1px solid #66afe9',
            boxShadow: 'inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px rgba(102, 175, 233, .6)',
            WebkitTransition: 'border-color ease-in-out .15s, -webkit-box-shadow ease-in-out .15s',
        },
        ':active' : {
            border: '1px solid #66afe9',
            boxShadow: 'inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px rgba(102, 175, 233, .6)',
            WebkitTransition: 'border-color ease-in-out .15s, -webkit-box-shadow ease-in-out .15s',

        }

    }

}

function validateContact(data) {
  const errors = {};
  if(!data.name) {
    errors.name = 'Required';
  }
  if(data.address && data.address.length > 50) {
    errors.address = 'Must be fewer than 50 characters';
  }
  if(!data.phone) {
    errors.phone = 'Required';
  } else if(!/\d{3}-\d{3}-\d{4}/.test(data.phone)) {
    errors.phone = 'Phone must match the form "999-999-9999"'
  }
  console.log( errors );
  return errors;
}

@connectReduxForm({
  form: 'contact',
  fields: ['name', 'address', 'phone'],
  validate: validateContact
})
@BamConfiguredRadium
export default class ContactForm extends Component {
  static propTypes = {
    fields: PropTypes.object.isRequired,
  }

  render() {

    const { fields: {name, address, phone}, handleSubmit } = this.props;
    console.log( name ); // output when hover.
    return (
      <form onSubmit={handleSubmit}>
        Name
        <input key="0" style={styles.base} type="text" {...name}/>

{name.error}

        Address
        <input key="1" type="text" style={styles.base} {...address}/>

{address.error}

        Phone
        <input key="2" style={styles.base} type="text" {...phone}/>

{phone.error}

        <button onClick={handleSubmit}>Submit</button>
      </form>
    );
  }
}

I have also tried PureRenderMixin but with no result.

Radium works by setting state and re-rendering components to apply new styles to them. If you're having performance issues, it might help to wrap your each of the input elements in a separate component so that only the input is re-rendered on hover.

But I'm not using ':hover' so I don't understand why a re-render is triggered. I have wrapped them in an own component now but still re-render when hovering.

Good catch! This is a vestige of the old active state support that would remove the active state when your mouse was no longer over the button. Since we don't do that anymore, radium shouldn't add mouse enter and leave listeners if you only use active styles.

authors: alexlande edgesoft ianobermiller

repo: FormidableLabs/radium


text:
Fix merge paragraph styles

@kenwheeler fix undo/redo during text editing, extend paragraph styles to cloned text elements for presentation mode and pdf export, explicitly add css properties for word break after resize is complete rather than during render method, (unless during drag state, which is necessary).

LGTM!

authors: mdaxtman rgerstenberger

repo: FormidableLabs/spectacle-editor


text:
Inconsistent error output on SSR rehydration

Description
1) 404 cases lead to different SSR and Browser representations of error.
2) SSR representation seems to be slightly off.
Steps to reproduce

Access 404 API from Browser directly (trigger SSR).
Access 404 API from Browser via link (trigger client fetching).

By 404 API I mean any API returning message: "Not Found", code: INTERNAL_SERVER_ERROR which is probably not perfect but is the default ApolloServer behavior:

AuthenticationError — for authentication failures
ForbiddenError — for authorization failures
UserInputError — for validation errors on user input
As a fallback for uncaught failures, any other unknown errors thrown within your resolver will add the code INTERNAL_SERVER_ERROR
https://blog.apollographql.com/full-stack-error-handling-with-graphql-apollo-5c12da407210

and shouldn't really matter for the context of this issue.
Code
// some NextJS page

let [dataResult] = useQuery({
  query,
})

if (dataResult.error) {
  console.log(dataResult.error) // !!!
  return <Error message={dataResult.error.toString()}/>
}

SSR Error
[CombinedError: [Network] undefined] {
  name: 'CombinedError',
  message: '[Network] undefined',
  graphQLErrors: [
    GraphQLError: Not Found
        at rehydrateGraphQlError (/.../node_modules/urql/dist/cjs/index-dddbd19e.js:23:12)
        at Array.map (<anonymous>)
        at new CombinedError (/.../node_modules/urql/dist/cjs/index-dddbd19e.js:39:61)
        ...
        at b (/.../node_modules/wonka/dist/wonka.js:865:14)
        at Array.forEach (<anonymous>) {
      message: 'Not Found'
    }
  ],
  networkError: Error: undefined
      at /.../node_modules/urql/dist/cjs/core.js:525:25
      ...
      at d (/.../node_modules/wonka/dist/wonka.js:137:16),
  response: undefined
}

error.toString() currently produces (at server) [Network] undefined.
Somehow it misses the informative  GraphQLError: Not Found part and goes for the weird  [Network] undefined
Browser
Talking about the same error in Browser.
error.toString() currently produces [GraphQL] Not Found.
Which LGTM.

The same error should probably lead to the same structures in Browser and Server.
At least, the error in Server should be improved to match the Browser one.
Stacktraces will be different for sure, but the final messages of toString should match IMO.

Hey, this is part of the latest urql release! Thanks for reporting this issue

authors: JoviDeCroock ivan-kleshnin

repo: FormidableLabs/urql


text:
Passing additional information to child of VictoryAnimation

Feature Request:
I am running into some cases where it would be very useful for the child of a VictoryAnimation component to know something about the state of the animation. In particular I'd like to be able to answer the questions:

Is this component currently animating or not?
If it is animating, what point are we at in the transition

A suggestion for how it could look, keeping things compatible with the current api
<Victory.VictoryAnimation data={dataObj}>
  {
    (tweened, animationInfo) => {
      return (
         <Child />
      )
    }
  }
</Victory.VictoryAnimation>

ETA 5/30 release

Resolved via https://github.com/FormidableLabs/victory-core/pull/94, not yet released.

authors: bmathews boygirl mathisonian

repo: FormidableLabs/victory-core


text:
Dummy test

This work introduces the first integration test for proteus using the dummy model. It checks the full data stored in runtime_helpfile.csvand compares all png plot output.

The test takes 11 min to run on the CI (instead of 3 min locally).
The coverage goes from 16% to 40%.
Results are not reproduced exactly from one run to another. See this passing and this not with same tolerance 1e-3.

Thanks for this, @lsoucasse. The coverage improvement is nice to see.
Regarding comparison of the helpfiles: does it tell you which variables are not up to the required tolerance? If it's on variables that don't matter too much, then this could be okay. If it's coming from the dummy test, then maybe it is associated with undefined behaviour in the last iteration?
Regarding the image comparison: if this is causing problems, maybe we can avoid using this method? If the check on the helpfile passes, then that should be sufficient, since the plot is only plotting the data in the helpfile anyway.

And a note on the model runtime: I have found that the model runs a lot faster if you change the plotting period to a larger number.

And a note on the model runtime: I have found that the model runs a lot faster if you change the plotting period to a larger number.

I can experiment with a lower dummy rate and see if it passes with lower tolerance. Would a value of 2e5 be relevant?
We only need the final plot so I guess setting the plot_iterfreq key to 0 would be OK?

Yeah 2e5 kg/s sounds okay. We could probably even do 1e4 kg/s.
Setting plot_iterfreq=0 should indeed prevent any plotting except in the final step.

Hi @lsoucasse I would say that if the plots are not reproducible, then that is a great result of having this test in the first place! I would avoid rescaling / increasing the tolerance to get the tests to pass, and instead mark the tests as xfail until we figure out what is causing the difference.

Hi @lsoucasse I would say that if the plots are not reproducible, then that is a great result of having this test in the first place! I would avoid rescaling / increasing the tolerance to get the tests to pass, and instead mark the tests as xfail until we figure out what is causing the difference.

But to me the plots are reproducible. I extracted the CI results using GH artefacts and I cannot see the difference. The diff plot in the comment above shows the frame and the labels which are artifical differences. I had to resize the images before comparing and I blame this step for creating these artificial differences and high rms.

Ah, could be font rendering or anti-aliasing settings.

With escape rate of 2e4 kg/s I can drop the tolerance down to 1e-4. And plotting only at the end reduces the total test run time to 4 min. I think plot_iterfreq=0 (or at least 50/100) should be the default option in all config files as is slows the code so much.
I set down the tolerance for the plots and flagged it with xfail. I will create an issue for solving this.

authors: lsoucasse nichollsh stefsmeets

repo: FormingWorlds/PROTEUS


text:
Browser Compatibility issues

Working fine on google chrome
but as i tested on the other browsers its not working fine like touch issues in firefox and safari
versions of the browsers are given bellow..
Firefox: 42.0 .
Safari: 5.1.7 .
please help me to sort out this issue

The touch-gestures are handled by the Hammer.js library. Maybe it needs to be updated?

authors: FrDH umairlodhi


text:
chore: add issue templates

we need to add few issue templates

docs
new feature
style changes
bug
others

please let's do separated issues for each of them

authors: FrancescoXX priyankarpal

repo: FrancescoXX/contentbox


text:
Support for Key Rollover

This PR addresses issue #25 and adds support for key rollover.
Certificates have to be specified in omejdn.yml.
Their public keys are then distributed via /.well-known/jwks.json, where each key is assigned a kid equal to its certificate's x5t thumbprint.
If an operator does not specify a certificate, a self-signed cert is created with two-day validity for testing purposes.

Before merging, I will fix a deviation from https://datatracker.ietf.org/doc/html/rfc7517#section-4.7, where certificates in a chain are supposed to appear in an array in x5c

Quick update:
OpenSSL::X509::Certificate currently does not have a function to load certificate chains. This is likely to change in a future update.
For now, I will implement a workaround for manually separating PEM encoded Certificates.

repo: Fraunhofer-AISEC/omejdn-server


text:
Ambiguous Challenge Instructions

Challenge Make Object Properties Private has an issue.
Please describe how to reproduce this issue, and include links to screenshots if possible.
Over the past couple days I've noticed a GH issue (#12385) and a few questions in the Javascript chat room about this challenge, all of which have all had to do with confusion about the purpose of the getGear and setGear functions. The challenge instructions explain private variables and private methods well, but doesn't explain the purpose of getters and setters.
I think adding a simple explanation of getters and setters without going too deep into encapsulation would benefit campers greatly. The new instructions would include something along these lines:

Getter functions such as getSpeed() are meant to simply return (get) the value of an object's private variable to the user without the user directly accessing the private variable.
Setter functions such as accelerate(change) are meant to modify (set) the value of an object's private variable based on the value passed into the setter function. This change could involve calculations, or even overwriting the previous value completely.

If people have other opinions on the current instructions or proposed changes, please share 😄

@robbawebba Thanks for the insight. Yep... I like the idea of more clarifications, but IMHO what you propose about getter and setter functions are more of a best practice/paradigm than just concept.
I am up for the change, but not really sure if this challenge's scope should be covering it or this should be a new challenge of itself.
/cc @FreeCodeCamp/moderators

Since the challenge asks you to define getGear and setGear I think the explanation would be welcome. Yes it is a paradigm, but it is a pretty standard one.
I'm :+1: for a change to the instructions

How about a one or two line introduction to Encapsulation? Along with private variables, it would serve as the basis for the need of getter and setter methods.

Does sound good. But again I am not convinced if all these should go into this challenge itself.

/cc @HKuz

@raisedadead I see what you mean about how encapsulation is more of a paradigm than a core concept of JavaScript, but I think that it does belong in this challenge because it is essentially already covering the "best practice" of encapsulation. It covers constructors for objects with private variables, and asks for campers to create public methods to access/modify the private variables (AKA encapsulation). So the challenge is already covering this topic but without explaining it fully. There's already sufficient explaination for constructors and private variables, but I think the discussion of setters and getters will help clear up any more confusion.

Thanks for flagging this for me, @raisedadead. So this challenge is in the current Object Oriented and Functional Programming section on FCC. Part of the curriculum expansion efforts created two new sections with new challenges (one for Objected Oriented Programming and one for Functional Programming) that will replace this one. The OOP section does cover encapsulation and private variables - if you're curious, you can check out the issue with the challenge list here. For getters and setters, the new ES6 section has a challenge specifically for the new get and set functions.
As for how to move forward - I really like how @robbawebba describes getter and setter up top. We can include it in the existing challenge, but know that ultimately, it'll be replaced once the curriculum expansion goes to production. I'd actually like to include those explanations in the ES6 challenge I linked to above. I think it would improve the challenge.
Of course, the timing to edit the new challenge right now is tough. The ES6 challenges are being pulled into the seed files this week as part of the big pull request to get the new challenges on the beta site. We may have to hang tight and wait for it to go live, then open an issue/PR to get that change in. In the meantime, I'll go edit the challenge on the issue, and we'll see if we beat Quincy's seeding efforts...

@robbawebba @HKuz thanks a lot for chiming in. From the way I see, if we do edit this challenge as you say it would be going into the same branch (staging) later.
So it's best as you say to let this wait and get this fixed in the curriculum expansion effort (even if this goes after an initial merge), as a second level pull request.
Count me in if you need help in anything, on merging it in.

@raisedadead @HKuz Sounds good for me! Thank you for the helpful information about the curriculum expansion - looking forward to it! I'd be happy to help if there's any way to get involved 🙂

@robbawebba sure thing, follow the issues on the https://github.com/FreeCodeCamp/CurriculumExpansion repo and join the conversation in the Contributors Chat room.

authors: Bouncey HKuz Manish-Giri raisedadead robbawebba

repo: FreeCodeCamp/FreeCodeCamp


text:
Changed the wording for Rule 3 in build a personal portfolio challenge

Pre-Submission Checklist

[X] Your pull request targets the staging branch of FreeCodeCamp.
[X] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[X] You have only one commit (if not, squash them into one commit).
[X] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[X] Bug fix (non-breaking change which fixes an issue)

*It was a wording change, but this seemed like the best match.

[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Add new translation (feature adding new translations)

Checklist:

[X] Tested changes locally.
[X] Closes currently open issue (Closes #XXXX): Closes #8340

Description

I changed the wording of rule 3 from "You may use your own CSS and frameworks other than Bootstrap" to "You can use Bootstrap, or any other framework of your choice." as suggested.

@BrianZ1 thanks for the PR! One small change though, can you change your git commit message to something like Fixed wording ambiguity for Personal Portfolio? We ask that issue numbers not be in the commit message. Keep the issue number within the checklist above though. Thanks!

I changed the message and I think it worked

@BrianZ1 thanks again! One more tiny change, can you add in a period at the end of Rule 3 right before the quotation?
"Rule #3: You can use Bootstrap, or any other framework of your choice.",

Uh, should I squash the commits too?

@BrianZ1 yes. Thanks!

I'm not entirely sure what I did, but I'm trying to fix it right now

@BrianZ1 you can reach out to the Contributors Help if you have any questions.

Do you mind if I start over from the beginning with a new pull request tomorrow morning? I feel like I messed up too much and starting over will be easier.

@BrianZ1 one quick question, are you using the command line to git commit? If so, I think I have the sequence of commands to help you out. You haven't messed up too much. Thanks for being persistent.

Yea, I am. I've been trying to use the rebase command and using squash, but I keep getting errors with that. Any help would be appreciated, but I'm too tired to think right now; I'll try it tomorrow morning if that's alright.

@BrianZ1 no worries. Whenever you get to it, here are the commands you can run that'll hopefully fix things. I checked out this PR and tested it myself. I'm assuming you've got the remote (upstream) and your local working branch (staging) setup correctly.
git checkout fix/rule-wording
git pull --rebase upstream staging
git rebase staging
git log # check if the last two commits are yours, if so proceed
git reset HEAD~2
git add basic-ziplines.json
git commit -m "	Fix wording ambiguity for Personal Portfolio"
git push origin fix/rule-wording --force

Hey, thanks for all the help. I'm not sure why it still shows the commit message of someone else though; will that be a problem? If it is, how would I go about fixing it?

@BrianZ1 yeah, it shouldn't say you've committed with another person, as that other commit has already been added. I'm out of ideas for how to fix it as I just tried fixing it again and it shows up for me too that you have that other commit. It might easier to close this PR and make another one. Visit the Gitter Contributors Help if you have any more questions. Thanks!

It only shows that I have one commit now, so I think whatever I did worked. Just to be sure, there's no way for me to change what the previous person commited, even if it doesn't show up anymore, right?

:sparkles: :sparkles: LGTM. :sparkles: :sparkles:
Thanks @BrianZ1 and @erictleung .

authors: BrianZ1 erictleung raisedadead


text:
FreeRDP console error ( OpenSSL LEGACY provider failed to load, no md4 support available! )

Hello! I have C++ code using the FreeRDP library.
I installed FreeRDP 3.4.0 using vcpkg, wrote code to connect to RDP from the console, but when I compiled and ran the console application, I received an error message.
Error message:

[20:09:06:227] [10560:00002094] [WARN][com.winpr.utils.ssl] - [winpr_openssl_initialize]: OpenSSL LEGACY provider failed to load, no md4 support available!
[20:09:08:514] [10560:00002094] [ERROR][com.freerdp.core] - [freerdp_tcp_is_hostname_resolvable]: ERRCONNECT_DNS_NAME_NOT_FOUND [0x00020005]
[20:09:10:794] [10560:00002094] [ERROR][com.freerdp.core.nego] - [nego_connect]: Failed to connect
Failed to connect to 1.

When installing FreeRdp using vkpkg, OpenSSL is also installed accordingly.
The code itself:
#include <freerdp/freerdp.h>
#include <freerdp/client.h>
#include <winpr/crt.h>
#include <winpr/synch.h>
#include <winpr/winsock.h>
#include <iostream>

bool connect_to_rdp(const char* hostname, const char* username, const char* password, const char* domain) {
    freerdp* instance = freerdp_new();
    if (!instance) {
        std::cerr << "Failed to create FreeRDP instance.\n";
        return false;
    }

    if (!freerdp_context_new(instance)) {
        freerdp_free(instance);
        std::cerr << "Failed to create FreeRDP context.\n";
        return false;
    }

    freerdp_settings_set_string(instance->context->settings, FreeRDP_ServerHostname, hostname);
    freerdp_settings_set_string(instance->context->settings, FreeRDP_Username, username);
    freerdp_settings_set_string(instance->context->settings, FreeRDP_Password, password);
    freerdp_settings_set_string(instance->context->settings, FreeRDP_Domain, domain);
    freerdp_settings_set_bool(instance->context->settings, FreeRDP_IgnoreCertificate, TRUE);

    if (freerdp_connect(instance)) {
        std::cout << "Successfully connected to " << hostname << ".\n";
        freerdp_disconnect(instance);
        freerdp_free(instance);
        return true;
    } else {
        std::cerr << "Failed to connect to " << hostname << ".\n";
        freerdp_free(instance);
        return false;
    }
}

int main(int argc, char* argv[]) {
    if (argc < 5) {
        std::cerr << "Usage: " << argv[0] << " <hostname> <username> <password> <domain>\n";
        return -1;
    }

    WSADATA wsaData;
    WSAStartup(MAKEWORD(2, 2), &wsaData);

    bool success = connect_to_rdp(argv[1], argv[2], argv[3], argv[4]);

    WSACleanup();

    return success ? 0 : 1;
}

My tasks.json:
{
    "tasks": [
        {
            "type": "cppbuild",
            "label": "C/C++: g++.exe сборка активного файла",
            "command": "c:\\msys64\\mingw64\\bin\\g++.exe",
            "args": [
                "-fdiagnostics-color=always",
                "-g",
                "${file}",
                "-o",
                "${fileDirname}\\${fileBasenameNoExtension}.exe",
                "-lwsock32",
                "-I",
                "C:\\vcpkg\\installed\\x64-windows\\include\\openssl", // openssl
                "-L",
                "C:\\vcpkg\\installed\\x64-windows\\lib",
                "-lcrypto",
                "-lssl",
                "-lWs2_32",
                "-I",
                "C:\\vcpkg\\installed\\x64-windows\\include",
                "-L",
                "C:\\vcpkg\\installed\\x64-windows\\lib",
                "-lfreerdp3",
                "-lfreerdp-client3",
                "-lcjson",
                "-llibusb-1.0",
                "-lzlib",
                "-lwinpr3",
                "-Wl,--subsystem,windows"

            ],
            "options": {
                "cwd": "c:\\msys64\\mingw64\\bin"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "detail": "Задача создана отладчиком."
        }
    ],
    "version": "2.0.0"
}

My settings.json:
{
    "C_Cpp.default.compilerPath": "C:\\msys64\\mingw64\\bin\\g++.exe",
    "files.associations": {
        "iosfwd": "cpp",
        "ostream": "cpp",
        "iostream": "cpp",
        "any": "cpp",
        "array": "cpp",
        "atomic": "cpp",
        "strstream": "cpp",
        "barrier": "cpp",
        "bit": "cpp",
        "*.tcc": "cpp",
        "bitset": "cpp",
        "cctype": "cpp",
        "cfenv": "cpp",
        "charconv": "cpp",
        "chrono": "cpp",
        "cinttypes": "cpp",
        "clocale": "cpp",
        "cmath": "cpp",
        "codecvt": "cpp",
        "compare": "cpp",
        "complex": "cpp",
        "concepts": "cpp",
        "condition_variable": "cpp",
        "coroutine": "cpp",
        "csetjmp": "cpp",
        "csignal": "cpp",
        "cstdarg": "cpp",
        "cstddef": "cpp",
        "cstdint": "cpp",
        "cstdio": "cpp",
        "cstdlib": "cpp",
        "cstring": "cpp",
        "ctime": "cpp",
        "cwchar": "cpp",
        "cwctype": "cpp",
        "deque": "cpp",
        "forward_list": "cpp",
        "list": "cpp",
        "map": "cpp",
        "set": "cpp",
        "string": "cpp",
        "unordered_map": "cpp",
        "unordered_set": "cpp",
        "vector": "cpp",
        "exception": "cpp",
        "expected": "cpp",
        "algorithm": "cpp",
        "functional": "cpp",
        "iterator": "cpp",
        "memory": "cpp",
        "memory_resource": "cpp",
        "numeric": "cpp",
        "optional": "cpp",
        "random": "cpp",
        "ratio": "cpp",
        "regex": "cpp",
        "source_location": "cpp",
        "string_view": "cpp",
        "system_error": "cpp",
        "tuple": "cpp",
        "type_traits": "cpp",
        "utility": "cpp",
        "rope": "cpp",
        "slist": "cpp",
        "format": "cpp",
        "fstream": "cpp",
        "future": "cpp",
        "initializer_list": "cpp",
        "iomanip": "cpp",
        "istream": "cpp",
        "latch": "cpp",
        "limits": "cpp",
        "mutex": "cpp",
        "new": "cpp",
        "numbers": "cpp",
        "ranges": "cpp",
        "scoped_allocator": "cpp",
        "semaphore": "cpp",
        "shared_mutex": "cpp",
        "span": "cpp",
        "spanstream": "cpp",
        "sstream": "cpp",
        "stacktrace": "cpp",
        "stdexcept": "cpp",
        "stdfloat": "cpp",
        "stop_token": "cpp",
        "streambuf": "cpp",
        "syncstream": "cpp",
        "thread": "cpp",
        "typeindex": "cpp",
        "typeinfo": "cpp",
        "valarray": "cpp",
        "variant": "cpp"
    },
    "makefile.makefilePath": ""
}

My launch.json:
{
    "configurations": [
        {
            "name": "C/C++: g++.exe сборка и отладка активного файла",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "c:\\msys64\\mingw64\\bin",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "c:\\msys64\\mingw64\\bin\\gdb.exe",
            "setupCommands": [
                {
                    "description": "Включить автоматическое форматирование для gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Задать для варианта приложения дизассемблирования значение Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: g++.exe сборка активного файла"
        }
    ],
    "version": "2.0.0"
}

My c_cpp_properties.json:
{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**",
                "C:\\msys64\\mingw64\\include\\",
                "C:\\libssh2\\include",
                "C:\\msys64\\mingw64\\include/**",
                "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.22621.0/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "cStandard": "c17",
            "cppStandard": "c++23",
            "intelliSenseMode": "windows-gcc-x64",
            "compilerArgs": [
                //"-lwsock32",
                //"-lssh2",
                //"-I C:\\libssh2\\include"
            ]
        }
    ],
    "version": 4
}

# vcpkg list:

cjson:x64-windows                                 1.7.17              Ultralightweight JSON parser i
n ANSI C
freerdp:x64-windows                               3.4.0#1             A free implementation of the R
emote Desktop Prot...
libusb:x64-windows                                1.0.27#1            a cross-platform library to ac
cess USB devices
openssl:x64-windows                               3.3.0               OpenSSL is an open source proj
ect that provides ...
pkgconf:x64-windows                               2.2.0               pkgconf is a program which hel
ps to configure co...
vcpkg-cmake-config:x64-windows                    2022-02-06#1
vcpkg-cmake-get-vars:x64-windows                  2023-12-31
vcpkg-cmake:x64-windows                           2023-05-04
vcpkg-msbuild:x64-windows                         2023-08-08
vcpkg-pkgconfig-get-modules:x64-windows           2023-09-06
vcpkg-tool-meson:x64-windows                      1.3.2#2             Meson build system
zlib:x64-windows                                  1.3.1               A compression library

# vcpkg version:
vcpkg package management program version 2024-03-14-7d353e869753e5609a1f1a057df3db8fd356e49d

See LICENSE.txt for license information.

I use:
Windows 10 x64
Visual Studio Code
Mingw GCC
vcpkg
FreeRDP 3.4.0
Who knows the solution? I would be very grateful for your help as I am new to C++

just as the error indicates, you need to properly configure your openssl.
RDP uses some outdated hash algorithms in some places.
we have the WITH_INTERNAL_MD4 et al options to compile them directly so no support in openssl is required.

authors: akallabeth denis-limanov

repo: FreeRDP/FreeRDP


text:
Freerdp Crash

Describe the bug
I was in the Windows session in Firefox and then edited my open Excel spreadsheet and then let Excel update the values and Freerdp just crashed.
To Reproduce
Steps to reproduce the behavior:
Cant reproduce.
Expected behavior
Freerdp does not crash.
Application details

FreeRDP version (xfreerdp /version)
This is FreeRDP version 3.9.1-dev0 (05801a162)
Command line used
/opt/freerdp-nightly/bin/xfreerdp3 /d:XXX /u:XXX /v:wints2012.kikxxl.corp /multimon /monitors:2,0 /sound /clipboard /sec:tls /cert:ignore /dynamic-resolution +auto-reconnect /rfx /log-level:trace 2>&1 | tee log.txt
Output of xfreerdp /buildconfig

[10:53:54:615] [180169:0002bfc9] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x623000000100]: *************************************************
[10:53:54:615] [180169:0002bfc9] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x623000000100]: This build is using [runtime-check] build options:
[10:53:54:615] [180169:0002bfc9] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x623000000100]: * 'WITH_VERBOSE_WINPR_ASSERT=ON'
[10:53:54:615] [180169:0002bfc9] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x623000000100]:
[10:53:54:615] [180169:0002bfc9] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x623000000100]: [runtime-check] build options might slow down the application
[10:53:54:615] [180169:0002bfc9] [WARN][com.freerdp.core.rdp] - [log_build_warn][0x623000000100]: *************************************************
This is FreeRDP version [/opt/freerdp-nightly/bin/xfreerdp3] 3.9.1-dev0 (05801a162)
[/opt/freerdp-nightly/bin/xfreerdp3] Build configuration: BUILD_TESTING=ON BUILD_TESTING_INTERNAL=OFF BUILD_TESTING_INTERNAL_AVAILABLE=0 WINPR_HAVE_AIO_H=1 WINPR_HAVE_EXECINFO_BACKTRACE=1 WINPR_HAVE_EXECINFO_BACKTRACE_SYMBOLS=1 WINPR_HAVE_EXECINFO_BACKTRACE_SYMBOLS_FD=1 WINPR_HAVE_EXECINFO_HEADER=1 WINPR_HAVE_FCNTL_H=1 WINPR_HAVE_GETLOGIN_R=1 WINPR_HAVE_GETPWUID_R=1 WINPR_HAVE_INTTYPES_H=1 WINPR_HAVE_POLL_H=1 WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= WINPR_HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 WINPR_HAVE_STDBOOL_H=1 WINPR_HAVE_STDINT_H=1 WINPR_HAVE_STRERROR_R=1 WINPR_HAVE_STRNDUP=1 WINPR_HAVE_SYSLOG_H=1 WINPR_HAVE_SYS_EVENTFD_H=1 WINPR_HAVE_SYS_FILIO_H= WINPR_HAVE_SYS_SELECT_H=1 WINPR_HAVE_SYS_SOCKIO_H= WINPR_HAVE_SYS_TIMERFD_H=1 WINPR_HAVE_TM_GMTOFF=1 WINPR_HAVE_UNISTD_H=1 WINPR_HAVE_UNWIND_H=1 WITH_AAD=ON WITH_ABSOLUTE_PLUGIN_LOAD_PATHS=ON WITH_ADD_PLUGIN_TO_RPATH=OFF WITH_ALSA=ON WITH_AVX2=OFF WITH_AVX2_AVAILABLE=0 WITH_BINARY_VERSIONING=ON WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CJSON_REQUIRED=OFF WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CLIENT_SDL=ON WITH_CLIENT_SDL2=ON WITH_CLIENT_SDL3=OFF WITH_CLIENT_SDL_AVAILABLE=1 WITH_CLIENT_SDL_VERSIONED=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_CODECS=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_EVENTS=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SCHANNEL=OFF WITH_DEBUG_SDL_EVENTS=OFF WITH_DEBUG_SDL_KBD_EVENTS=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DOCUMENTATION=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_DSP_FFMPEG_AVAILABLE=1 WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FDK_AAC=ON WITH_FFMPEG=ON WITH_FREERDP_DEPRECATED=OFF WITH_FREERDP_DEPRECATED_COMMANDLINE=ON WITH_FULL_CONFIG_PATH=OFF WITH_FUSE=ON WITH_GFX_FRAME_DUMP=OFF WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_INSTALL_CLIENT_DESKTOP_FILES=OFF WITH_INTERNAL_MD4=ON WITH_INTERNAL_MD5=ON WITH_INTERNAL_RC4=ON WITH_JPEG=OFF WITH_JSONC_REQUIRED=OFF WITH_JSON_DISABLED=OFF WITH_KEYBOARD_LAYOUT_FROM_FILE=ON WITH_KRB5=ON WITH_KRB5_NO_NTLM_FALLBACK=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBRESSL=OFF WITH_LODEPNG=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_NATIVE_SSPI=OFF WITH_NEON=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSSL=ON WITH_OPUS=ON WITH_OSS=ON WITH_PCSC=ON WITH_PKCS11=ON WITH_PLATFORM_SERVER=ON WITH_POLL=ON WITH_PROFILER=OFF WITH_PROXY=ON WITH_PROXY_APP=ON WITH_PROXY_EMULATE_SMARTCARD=OFF WITH_PROXY_MODULES=ON WITH_PULSE=ON WITH_RDTK=ON WITH_RESOURCE_VERSIONING=ON WITH_SAMPLE=ON WITH_SANITIZE_ADDRESS=ON WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=0 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=0 WITH_SDL_IMAGE_DIALOGS=ON WITH_SDL_LINK_SHARED=ON WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_EMULATE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SMARTCARD_PCSC=ON WITH_SOXR=OFF WITH_SSE2=OFF WITH_SWSCALE=ON WITH_SYSTEMD=ON WITH_THIRD_PARTY=OFF WITH_TIMEZONE_COMPILED=ON WITH_TIMEZONE_FROM_FILE=ON WITH_TIMEZONE_ICU=OFF WITH_UNICODE_BUILTIN=OFF WITH_URIPARSER=ON WITH_VAAPI=OFF WITH_VAAPI_AVAILABLE=1 WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=0 WITH_VERBOSE_WINPR_ASSERT=ON WITH_VIDEO_FFMPEG=ON WITH_VIDEO_FFMPEG_AVAILABLE=1 WITH_WAYLAND=ON WITH_WEBVIEW=OFF WITH_WINPR_DEPRECATED=OFF WITH_WINPR_JSON=ON WITH_WINPR_TOOLS=ON WITH_WINPR_UTILS_IMAGE_JPEG=ON WITH_WINPR_UTILS_IMAGE_PNG=ON WITH_WINPR_UTILS_IMAGE_WEBP=ON WITH_WIN_CONSOLE=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XV=ON
Build type:          RelWithDebInfo
CFLAGS:              -g -O2 -ffile-prefix-map=<src dir>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -fPIC -Wall -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fsanitize=address -fsanitize-address-use-after-scope -O2 -g -DNDEBUG
Compiler:            GNU, 10.2.1
Target architecture: x64

OS version connecting to (server side)
Windows Terminal Server 2016
If available the log output from a run with /log-level:trace 2>&1 | tee log.txt
log.zip

Environment (please complete the following information):

OS: Linux
Version/Distribution: Debian 11
Architecture: amd64

@akallabeth
When i Copy from Excel and print to Lokal Libreoffice then its Crash with the newest version :/
System:
Lokal = Debian 11
Remote = Windows terminal Server 2016
Command i use:
/opt/freerdp-nightly/bin/xfreerdp3 /d:XXX /u:XXX /v:XXX /sound /clipboard /sec:tls /cert:ignore /dynamic-resolution +auto-reconnect /rfx /log-level:trace 2>&1 | tee log.txt
Version:
This is FreeRDP version 3.9.1-dev0 (48ada610e)
Log:
log.txt

@xBr0th3rx
[16:25:15:106] [3116815:002f8f9e] [TRAC[16:25:15:110] [3116815:002f8f9e] [ERROR][com.freerdp.client.x11] - [xf_error_handler]: BadLength (poly request too large or internal Xlib length error)
this means update your system, you X11 does not support such large values. (not much we can do in this case)

you try to copy a 21 MB bitmap to server, right?

i Copyed 2 columns with 1000 lines
Locally it is apparently inserted as hyptertext by default
if I insert locally as unformatted text then it does not crash

@xBr0th3rx did find something:
https://stackoverflow.com/questions/67813915/xlib-how-to-correctly-cancel-the-process-of-incremental-data-transfer
X11 has a limit of ~20MB for single data requests, so that does not work for large data.

@xBr0th3rx I´ve just tried with current master on my debian 12 with very large images and html pages.
works fine with incremental reading without the BadLength error or yours, so most likely a bug in your system :/

Hey,
I had tested it again and it works without crashing. Tested on several desktops.


text:
Garbled/invisible pointer with Microsoft Remote Desktop 8 android app

I'm using Microsoft Remote Desktop 8 android app to connect to a shadow Linux Mint remote desktop using a nightly freerdp-shadow-cli.
The issue is that the mouse pointer is garbled or not shown at all in the server android app. Although the pointer works and moves (you have to guess where is pointing). See the image below with the garbled pointer icon.
Connecting with that same RD8 app to a native Windows 10, 7 or even XP remote desktop don't show this issue.
Connecting with a native Microsoft Terminal Services Client (mstsc.exe or tsclient.exe) to freerdp-shadow-cli -auth instead of the RD8 app the mouse pointer also is shown fine (but I think that these may be local pointers instead of being rendered at the remote end as RD8 seems to use?).
)
$ xfreerdp /buildconfig
This is FreeRDP version 3.0.0-dev (cb0cba2)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_INTTYPES_H=1 HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=OFF WITH_DSP_FFMPEG=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_FUSE=OFF WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PROXY=ON WITH_PROXY_MODULES=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=ON WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=0 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=0 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VAAPI=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=0 WITH_WAYLAND=ON WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          RelWithDebInfo
CFLAGS:              -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fno-omit-frame-pointer -fsanitize=address -DWINPR_DLL
Compiler:            GNU, 5.4.0
Target architecture: x64

The remote desktop is Linux Mint 18.3 (Ubuntu xenial base)
RD 8 app latest version 8.1.81.435 (android 6.0 and 11)
The remote client service is started with $ freerdp-shadow-cli /sec:rdp
Note that there is no freerdp-shadow package available for Linux Mint 18.3, so I copied the Build configuration from the Linux Mint 20 FreeRDP version 2.2.0 distribution package to compile it myself.
Also tried to compile it with only the default flags shown in the wiki but adding -DWITH_SHADOW=ON seems that is not enough to get a freerdp-shadow-cli executable.
May be some compile flags above could be changed to fix this pointer issue?

can you reproduce this with desktop clients as well? I´ve tried with windows 10 client and could not reproduce.

also, does this also happen with the current android client (10)?

can you reproduce this with desktop clients as well? I´ve tried with windows 10 client and could not reproduce.

No with the native Microsoft Terminal Services Client (mstsc.exe and tsclient.exe). These show the local pointer fine as stated earlier.

Connecting with a native Microsoft Terminal Services Client (mstsc.exe or tsclient.exe) to freerdp-shadow-cli -auth instead of the RD8 app the mouse pointer also is shown fine (but I think that these may be local pointers instead of being rendered at the remote end as RD8 seems to use?

also, does this also happen with the current android client (10)?

Not sure what "current android client (10)" you mean. Can't test the Microsoft RD8 client with android 10, only had available 4.4, 6.0 and 11.
I tried to test this issue using another freerdp based android aRDP client app with an android 6.0 phone but it crashed systematically with a java exception when attempting to connect.
RD 8 app version 8.1.81.435 is the latest available in the Playstore and shows this same pointer issue in android 4.4, 6.0 and 11 with this nightly freerdp-shadow-cli also tested in another Linux Mint 20 (Ubuntu focal base) default install.

@lulol I meant the newer android rdp client, 8 is old
https://play.google.com/store/apps/details?id=com.microsoft.rdc.androidx tells me the current one is 10.0.9.1122

@akallabeth Thanks for the link. I was confused because wasn't aware of this newer version.
In any case the RD8 app was updated just a few months ago and the newer RD10 won't work with older android devices.
Installed that RD version 10 in android 11 but have been unable to test this pointer issue with it because with this app all the display is shown garbled. Works fine with other Microsoft remote desktop servers.
Have been playing with the app display options and freerdp-shadow /rect:<x,y,w,h> to try to match the phone aspect ratio, but to no avail.
The screenshot below is from RD10 and the pointer looks ok but since the background is black can't be noticed, and also sometimes the pointer is not visible at all.

Although probably unrelated to this pointer issue, what have also found is that the latest Parallels tsclient.exe, and Windows7 and Windows8.1 mstsc.exe they connect, show the remote desktop and then closes the connection with a protocol error.
With the mstsc.exe of Win10 and WinXP both work as expected and the pointer is fine.
nightly freerdp-shadow-cli tested in a Linux Mint 20 (Ubuntu focal base) default install.
Log with Windows8.1 mstsc.exe
$ WLOG_LEVEL=debug /opt/freerdp-nightly/bin/freerdp-shadow-cli /sec:rdp
[19:23:31:498] [473702:473702] [INFO][com.freerdp.server.shadow.x11] - X11 Extensions: XFixes: 1 Xinerama: 1 XDamage: 0 XShm: 0
[19:23:31:505] [473702:473702] [INFO][com.freerdp.core.listener] - Listening on [0.0.0.0]:3389
[19:23:31:505] [473702:473702] [INFO][com.freerdp.core.listener] - Listening on [::]:3389
[19:24:04:689] [473702:473703] [DEBUG][com.winpr.thread] - Thread running, setting to detached state!
[19:24:04:700] [473702:473753] [DEBUG][com.freerdp.core.nego] - RDP_NEG_REQ: RequestedProtocol: 0x0000000B
[19:24:04:700] [473702:473753] [INFO][com.freerdp.core.connection] - Client Security: NLA:1 TLS:1 RDP:0
[19:24:04:700] [473702:473753] [INFO][com.freerdp.core.connection] - Server Security: NLA:0 TLS:0 RDP:1
[19:24:04:700] [473702:473753] [ERROR][com.freerdp.core.connection] - server supports only Standard RDP Security
[19:24:04:700] [473702:473753] [ERROR][com.freerdp.core.connection] - Protocol security negotiation failure
[19:24:04:708] [473702:473753] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_INITIAL - rdp_server_accept_nego() fail
[19:24:04:708] [473702:473753] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[19:24:04:708] [473702:473753] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
[19:24:04:708] [473702:473753] [ERROR][com.freerdp.client.shadow] - Failed to check FreeRDP file descriptor
[19:24:07:399] [473702:473703] [DEBUG][com.winpr.thread] - Thread running, setting to detached state!
[19:24:07:411] [473702:473754] [DEBUG][com.freerdp.core.nego] - RDP_NEG_REQ: RequestedProtocol: 0x00000000
[19:24:07:411] [473702:473754] [INFO][com.freerdp.core.connection] - Client Security: NLA:0 TLS:0 RDP:1
[19:24:07:411] [473702:473754] [INFO][com.freerdp.core.connection] - Server Security: NLA:0 TLS:0 RDP:1
[19:24:07:411] [473702:473754] [INFO][com.freerdp.core.connection] - Negotiated Security: NLA:0 TLS:0 RDP:1
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.connection] - Accepted client: WIN8
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.connection] - Accepted channels:
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.connection] -  rdpdr
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.connection] -  rdpsnd
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.connection] -  cliprdr
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.connection] -  drdynvc
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.gcc] - Active rdp encryption level: CLIENT-COMPATIBLE
[19:24:13:660] [473702:473754] [INFO][com.freerdp.core.gcc] - Selected rdp encryption method: 128BIT
[19:24:13:849] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_CONFIRM_ACTIVE
[19:24:13:849] [473702:473754] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x1f size=49 channelId=1009)
[19:24:13:849] [473702:473754] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x14 size=53 channelId=1009)
[19:24:13:850] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:13:850] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:13:850] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:13:850] [473702:473754] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x14 size=53 channelId=1009)
[19:24:13:852] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:13:852] [473702:473754] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x28 size=53 channelId=1009)
[19:24:13:852] [473702:473754] [INFO][com.freerdp.client.shadow] - Client from 192.168.1.93 is activated (1920x1080@16)
[19:24:13:989] [473702:473754] [DEBUG][com.freerdp.client.shadow] - initializing RemoteFX encoder
[19:24:13:999] [473702:473754] [DEBUG][com.freerdp.primitives] - primitives benchmark result:
[19:24:13:163] [473702:473754] [DEBUG][com.freerdp.primitives] -  * generic= 23
[19:24:14:317] [473702:473754] [DEBUG][com.freerdp.primitives] -  * optimized= 37
[19:24:14:317] [473702:473754] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[19:24:14:512] [473702:473789] [DEBUG][com.freerdp.channels.rdpsnd.server] - Client requested sound quality: 0x0000
[19:24:14:513] [473702:473754] [INFO][com.freerdp.client.shadow] - Gfx Pipeline Opened
[19:24:14:689] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:14:689] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:14:690] [473702:473799] [DEBUG][com.freerdp.client.shadow] - initializing H.264 encoder
[19:24:14:713] [473702:473798] [ERROR][com.freerdp.channels.audin.server] - WTSVirtualChannelQuery failed
[19:24:14:825] [473702:473754] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:24:14:947] [473702:473754] [ERROR][com.freerdp.core.transport] - error when flushing outputBuffer
[19:24:14:947] [473702:473754] [ERROR][com.freerdp.core] - transport_default_write:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[19:24:14:947] [473702:473754] [ERROR][com.freerdp.client.shadow] - Send surface bits(RemoteFxCodec) failed
[19:24:14:947] [473702:473754] [ERROR][com.freerdp.client.shadow] - Failed to send surface update

Log with android app Microsoft RD 10.0.9.1122:
[19:43:35:162] [475327:475328] [DEBUG][com.winpr.thread] - Thread running, setting to detached state!
[19:43:35:173] [475327:475686] [DEBUG][com.freerdp.core.nego] - RDP_NEG_REQ: RequestedProtocol: 0x0000000B
[19:43:35:173] [475327:475686] [INFO][com.freerdp.core.connection] - Client Security: NLA:1 TLS:1 RDP:0
[19:43:35:173] [475327:475686] [INFO][com.freerdp.core.connection] - Server Security: NLA:0 TLS:0 RDP:1
[19:43:35:173] [475327:475686] [ERROR][com.freerdp.core.connection] - server supports only Standard RDP Security
[19:43:35:173] [475327:475686] [ERROR][com.freerdp.core.connection] - Protocol security negotiation failure
[19:43:37:589] [475327:475686] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_INITIAL - rdp_server_accept_nego() fail
[19:43:37:589] [475327:475686] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[19:43:37:589] [475327:475686] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
[19:43:37:589] [475327:475686] [ERROR][com.freerdp.client.shadow] - Failed to check FreeRDP file descriptor
[19:43:37:615] [475327:475328] [DEBUG][com.winpr.thread] - Thread running, setting to detached state!
[19:43:37:625] [475327:475687] [DEBUG][com.freerdp.core.nego] - RDP_NEG_REQ: RequestedProtocol: 0x00000000
[19:43:37:625] [475327:475687] [INFO][com.freerdp.core.connection] - Client Security: NLA:0 TLS:0 RDP:1
[19:43:37:625] [475327:475687] [INFO][com.freerdp.core.connection] - Server Security: NLA:0 TLS:0 RDP:1
[19:43:37:625] [475327:475687] [INFO][com.freerdp.core.connection] - Negotiated Security: NLA:0 TLS:0 RDP:1
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.connection] - Accepted client: SG
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.connection] - Accepted channels:
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.connection] -  rdpdr
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.connection] -  rdpsnd
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.connection] -  cliprdr
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.connection] -  drdynvc
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.gcc] - Active rdp encryption level: CLIENT-COMPATIBLE
[19:43:37:629] [475327:475687] [INFO][com.freerdp.core.gcc] - Selected rdp encryption method: 128BIT
[19:43:37:721] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_CONFIRM_ACTIVE
[19:43:37:721] [475327:475687] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x1f size=49 channelId=1009)
[19:43:37:721] [475327:475687] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x14 size=53 channelId=1009)
[19:43:37:723] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:43:37:724] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:43:37:725] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:43:37:725] [475327:475687] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x14 size=53 channelId=1009)
[19:43:37:729] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:43:37:729] [475327:475687] [DEBUG][com.freerdp.core.rdp] - rdp_send_data_pdu: sending data (type=0x28 size=53 channelId=1009)
[19:43:37:729] [475327:475687] [INFO][com.freerdp.client.shadow] - Client from 192.168.1.102 is activated (1920x1080@32)
[19:43:37:821] [475327:475687] [DEBUG][com.freerdp.client.shadow] - initializing NSCodec encoder
[19:43:37:892] [475327:475688] [DEBUG][com.freerdp.channels.rdpsnd.server] - Client requested sound quality: 0x0000
[19:43:37:894] [475327:475687] [INFO][com.freerdp.client.shadow] - Gfx Pipeline Opened
[19:43:37:112] [475327:475694] [DEBUG][com.freerdp.client.shadow] - initializing H.264 encoder
[19:43:37:122] [475327:475694] [DEBUG][com.freerdp.primitives] - primitives benchmark result:
[19:43:38:288] [475327:475694] [DEBUG][com.freerdp.primitives] -  * generic= 21
[19:43:38:370] [475327:475693] [DEBUG][com.freerdp.channels.audin.server] - WAVE_FORMAT_PCM:     wFormatTag: 0x0001 nChannels: 2 nSamplesPerSec: 44100 nAvgBytesPerSec: 176400 nBlockAlign: 4 wBitsPerSample: 16 cbSize: 0
[19:43:38:382] [475327:475693] [WARN][com.freerdp.server.shadow] - AudinServerOpenResult not implemented
[19:43:38:382] [475327:475693] [INFO][com.freerdp.server.shadow] - AUDIN open result 0.
[19:43:38:445] [475327:475694] [DEBUG][com.freerdp.primitives] -  * optimized= 36
[19:43:38:445] [475327:475694] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[19:44:15:285] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:44:19:103] [475327:475687] [DEBUG][com.freerdp.core.peer] - Received PDU_TYPE_DATA
[19:44:32:931] [475327:475687] [ERROR][com.freerdp.core.peer] - Incorrect RDP header.
[19:44:32:931] [475327:475687] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_ACTIVE - peer_recv_pdu() fail
[19:44:32:931] [475327:475687] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[19:44:32:931] [475327:475687] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1
[19:44:32:931] [475327:475687] [ERROR][com.freerdp.client.shadow] - Failed to check FreeRDP file descriptor

@lulol ok, tested with current nightly on debian bullseye here and I can´t reproduce.
Tested:

Windows 10
Windows 7
Android Remote Desktop 8

did not manage to get the android remote desktop 10 client to connect, always wanted NLA security, which is not supported by shadow.

Have checked with 2 different computers and several android devices. Same result. May be is a Linux Mint related issue with freerdp-shadow.
Garbled pointer is visible at the top-right of the window bar.
Live Linux Mint 20 iso
freerdp-nightly
Microsoft Remote Desktop 8

Latest Live Linux Mint 20.1 iso
Same nightly freerdp-shadow and RD8 app.

Same latest Live Linux Mint 20.1 iso, same nightly freerdp-shadow and latest RD10 app.

Also had similar results with the same software shown above on different combinations of computers/phones.
To connect to the shadow server with the RD10 app you may try to setup a user/pass in the app and choose it for the connection even if later won't need to use it.

@lulol did you try and simply change the cursor theme? maybe it is a bug (or triggered) in the cursor image?

Tried changing the pointer and desktop theme as suggested. Also tried to disable all the effects. Didn't find other mouse pointer options that seemed relevant. Still is shown garbled.

@akallabeth What more feedback are you expecting that I could provide?
If I can help doing some other test, please advise.

authors: akallabeth lulol


text:
Fix scrolling crash in wayland client

An "axis discrete" handler is required since protocol version 5:
https://code.woboq.org/qt5/include/wayland-client-protocol.h.html#_M/WL_POINTER_AXIS_SOURCE_SINCE_VERSION
Since this was not defined, wlfreerdp would crash with the error message "listener function for opcode 8 of wl_pointer is NULL" if the user attempted to scroll.

@freerdp-bot would you test that please ?


text:
[client,Android] Fix clipboard server-to-client

Fix android server-to-client clipboard
Reproduce - connect to win7/win10 computer, and try to copy some text in connection, then paste it in another android app
Tested on win7/winserver2022
And few questions...

What is "UTF8_STRING" constant (android_cliprdr.c:425)? Why we trying to register this clipboard format, but requesting format is CF_TEXT/CF_UNICODETEXT (android_cliprdr.c:255)?
Is windows/xrdp servers always send CF_UNICODETEXT? I thing it is defined by application, which paste data into clipboard, and in this case it is worth doing some conversion using CF_LOCALE
Is CF_UNICODETEXT is always UTF-16? All unicode in winapi is utf-16-le, but, if something went wrong.....

added the fix to #9248 (just use text/plain as format)

authors: akallabeth weoses


text:
'uint8_t' does not name a type

Hi,
I got these errors when my code include cellular library headers only.
Incude:
#include <cellular_config.h>
#include <cellular_config_defaults.h>
#include <cellular_comm_interface.h>

Error:
../Lib/FreeRTOS-Cellular-Interface/source/include/cellular_types.h:416:5: error: 'uint8_t' does not name a type

I think it would be better to include stdint.h here.
https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface/blob/main/source/include/cellular_types.h#L39

Thank you for the feedback. I will fix this ASAP.

The issue is fixed in this PR. Once it is merged I will close this issue.
https://github.com/FreeRTOS/FreeRTOS-Cellular-Interface/pull/53

authors: chinglee-iot matsujirushi

repo: FreeRTOS/FreeRTOS-Cellular-Interface


text:
Demo: Cortex m4 mpu mps2 with qemu

Demo: Cortex m4 mpu mps2 with qemu
Description
Demo: Cortex m4 mpu mps2 with qemu
Test Steps
manual testing with qemu
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Looks reasonable. Can we easily target other mps2 boards with the same project?

repo: FreeRTOS/FreeRTOS


text:
This is a demo issue

this is to practice how issues work!

Can you please assign this issue to me ? @Frenzyritz13

/assign @Frenzyritz13


text:
🛑 Sakura Sekretariat-DJPb is down

In 3b2b898, Sakura Sekretariat-DJPb (http://sakura.setditjen-djpb.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sakura Sekretariat-DJPb is back up in cb3f6fb.

repo: FrideyAlpha/uptime-setditjen


text:
🛑 Drone Sekretariat-DJPb is down

In bbf6d99, Drone Sekretariat-DJPb (https://drone.setditjen-djpb.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Drone Sekretariat-DJPb is back up in c476230.


text:
fix:LGAlertView 在xcode14.3 报错问题

fix:LGAlertView 在xcode14.3 报错问题

xcode14.3 报错问题

Who will merge this pull request?

authors: rahulvyas yinyakun

repo: Friend-LGA/LGAlertView


text:
Adding a .varci.yaml

This may not be necessary for this repo as the amount of change requests is usually low, but is very cool nevertheless 💃
This should at least help automate some of the tedium of maintaining the list and communicating with contributors.

Let's give this a try :+1:

Do we need some docs/readme update or some contribution file explaining what to do here?

Woohoo!! 🚀
@dereuromark docs can be found here for now: https://github.com/VarCI/support/blob/master/pages/documentation.md. Let me know if you had something else in mind and I will get it PR'd later today.
Thanks for giving it a shot!

I mean for people making a PR for this repo. They would need the info in a texual way to know what are the requirements for the PR to pass :)

I think the messages set for message keys is what will be shown to users.

authors: ADmad dereuromark jadb lorenzo

repo: FriendsOfCake/awesome-cakephp

license: WTFPL


text:
Deprecated TEMPLATE_LOADERS

TEMPLATE_LOADERS in core/settings/stage + prod is deprecated.

Solved since a9d1c04deae4ba0d795b5591cd2b15ea09203ead

authors: marteinn martinjobb

repo: Frojd/Frojd-Django-Boilerplate


text:
Broken link in quickstart page

Reported by @Rubyt0x
https://github.com/FuelLabs/fuel-docs/blob/d991c21d714f2e81948f33c4471784fc52bc0e42/src/developer-quickstart.md?plain=1#L34

Fixed via https://github.com/FuelLabs/fuel-docs/pull/30

authors: adlerjohn camiinthisthang

repo: FuelLabs/fuel-docs


text:
Fixes ambiguity on two diff structs with same arg name

Fixes https://github.com/FuelLabs/fuels-rs/issues/77.
Also simplifies some things related to custom types.

@vnepveu just a heads up: this PR changes some things related to custom types, which means I had to make some small tweaks to the custom types abigen that you've created recently. No big changes though.

repo: FuelLabs/fuels-rs


text:
feat: add helper method to Abi Interface

this PR is created in cascade mode from #1113 .. it should be reviewed after it gets merged.
Problem:
As now the old ABI format is removed, we don't have easy access to type of ABI fragments anymore
Solution:
implements a new helper method getTypeById, the objective is to provide an easy way to get abi types:
Usage:
const abiInterface = new Interface(abi);

const abiType = abiInterface.getTypeById(10);

@nedsalk More breaking changes?

authors: LuizAsFight arboleya

repo: FuelLabs/fuels-ts


text:
rc: salamander

[x] #1496
[x] #1403
[x] #1374
[x] #1445
[x] #1497
[ ] #1474
[x] #1583
[x] #1310
[x] #1575

It seems we have a flaky test on Salamander RC: https://github.com/FuelLabs/fuels-ts/actions/runs/7301835259/job/19899474795#step:9:329

It seems we have a flaky test on Salamander RC: https://github.com/FuelLabs/fuels-ts/actions/runs/7301835259/job/19899474795#step:9:329
UPDATE: It is also happening locally, but not always.

Are we running tests concurrently? A possible case for this one to be flaky is that some additional(s) block(s) may be produced or not during this test.

Yes, the Vitest migration in #1310 means a lot of tests run concurrently, and differently to how they were with jest, hence the performance improvements. I'll look into isolating this test.

authors: Torres-ssf arboleya danielbate


text:
remove_deps cannot handle removed dependencies correctly when there are multiple roots after edge removal

Currently, remove_deps first removes edges and then removes the nodes with no incoming edge, in parent to child direction, which can be seen from here. Because of #1778, remove_deps wasn't executed in package removal scenarios. But with #1784, after patching a dependency and removing the patch from Forc.toml, I realized that the BuildPlan generation from the lock file succeeds but packages are not removed correctly.
Since the edges are removed first, we cannot reach subgraphs that are now unconnected to the original root of the graph while doing a BFS from the root node. Which means they are not deleted.
At the beginning

After edge removal

Proposed Solution
We can remove the nodes (that are either one of the removed ones or have no incoming edge) while doing the BFS rather than removing the edges first. I think removing the node also invokes the removal of the edges for the removed node.
Or we can keep track of the new roots that emerged while removing the edges and do separate BFS from each of the roots we found.
cc @mitchmindtree

Since the edges are removed first, we cannot reach subgraphs that are now unconnected to the original root of the graph while doing a BFS from the root node

Good spot!
Yeah I think your proposal makes sense. To clarify: after edge removal, rather than doing a BFS we can instead iterate over all nodes in reverse compilation order (that is, the compilation order before edge removal occurred, no need to recalculate it first) and remove every node that has no parent (i.e. no incoming edges).

authors: kayagokalp mitchmindtree

repo: FuelLabs/sway


text:
Add booleans to the keywords in the parser

Simple PR to add booleans as a keyword in the parser

This looks a bit out of place.  true and false aren't intrinsic functions really.
How does this improve things though?  Maybe we need the concept of predefined axiomatic values in the compiler, perhaps slightly higher level than as intrinsics, but I don't quite know why.

+1 on it's not immediately obvious why this is needed. Also weird that they're not prefixed with __ (which might hint that they shouldn't be intrinsics).

The word "intrinsics" is often used as a short-hand way of referring to "intrinsic functions." I believe that, philosophically, most compilers also contain "intrinsic expressions". For example, in the case of Sway, unsigned ints are lifted to the compiler level inside of TypeInfo::Str and TypeInfo::Array, thus making those unsigned ints intrinsic expressions.
In the context of the parser, I was mistakenly under the impression that Intrinsic meant """ a special case that has intrinsic value to the compiler """. If at parse time Intrinsic is meant to represent just intrinsic functions, then I recommend that we change the name to IntrinsicFunctionName or add doc strings to this type.
I think that the "true" and "false" tokens are hooks into compile-time knowledge of the conversion from the "true" token to true and from the "false" token to false (without which they would be parsed as variables). Introducing IntrinsicFunctionName would allow us to introduce IntrinsicExpression, which would just contain "true" and "false".
But I think I am just splitting hairs about this now 😄

it's not immediately obvious why this is needed

This change is used in the following PR https://github.com/FuelLabs/sway/pull/1646, but I broke it into its own PR for readability.

Could you speak to how this follows those conventions and what makes it future-proofing?

I don't know specifically how Rust and LLVM handle the conversion between the "true" token to true and from the "false" token to false. But it terms of future-proofing, this change makes it a little more clear where the "true" and "false" tokens are parsed.

true and false are really just keywords: https://doc.rust-lang.org/reference/keywords.html

Works for me @mohammadfawaz !

@otrho are you okay with moving towards making true and false keywords as Emily has done is her latest commit?

authors: adlerjohn emilyaherbert mohammadfawaz otrho


text:
Regarding engine forks and whatnot

Alright, I believe we should be a little harsh when it comes to engine forks.
Any engine forks that include not that many QoL changes, have miscellaneous changes (like a new HUD) that can be made with a script within 5 to 10 minutes, should be automatically rejected.
There are, obviously, exception, for example: the Raltyro Psych Fork, Pluma's Psych Fork and others that I can't think of at the top of my head.
(feel free to pin this btw)

Custom Psych Engine too!!
(this is a joke, it doesn't have any progress, and there's a newer version in works which i've stopped working on months ago)

more or less i think. if someone looks at the changes, and they dont think they are super incredible awesome or interesting , can be rejected

Most of the stuff they add (specifically psych forks) are already replicated in lua by the base Psych community too.

damn, didn't know that. the only fork i know of (os engine) changes some menu stuff and adds new options (that i personally think are too much)

damn, didn't know that. the only fork i know of (os engine) changes some menu stuff and adds new options (that i personally think are too much)

I checked the os engine readme and yeah all of the OS Engine features (other than the menus) can be recreated in base Psych 0.6.3, including shaders lol

There's a lot of psych ports just using lua scripts (lmao)

There's a lot of psych ports just using lua scripts (lmao)

Most of them aren't theirs either too

more or less i think. if someone looks at the changes, and they dont think they are super incredible awesome or interesting , can be rejected

I feel like a section related to this should be added to the Code of Conduct file

more or less i think. if someone looks at the changes, and they dont think they are super incredible awesome or interesting , can be rejected

I feel like a section related to this should be added to the Code of Conduct file

https://github.com/sindresorhus/awesome/blob/main/awesome.md
"Research if the stuff you're including is actually awesome."

more or less i think. if someone looks at the changes, and they dont think they are super incredible awesome or interesting , can be rejected

I feel like a section related to this should be added to the Code of Conduct file

https://github.com/sindresorhus/awesome/blob/main/awesome.md "Research if the stuff you're including is actually awesome."

Only a suggestion, but fair enough, should've probably read the manifesto and stuff lol

Should this issue be closed? I don't really know where to take this discussion from here, this was just for raising awareness, not gonna lie. It can be a pinned issue if possible.

i think that the pinned issue should be the first one made (the Add Descriptions To Links? one)

oh well lol

Closing this as #51 resolves this issue.

authors: BombasticTom Burgerballs doggogit ninjamuffin99

repo: FunkinCrew/funkin-resources


text:
🛑 Home Assistant is down

In a79074d, Home Assistant (https://ha.fussel.tv) was down:

HTTP code: 530
Response time: 121 ms

Resolved: Home Assistant is back up in 4608c5f.

repo: FusselTV/status


text:
build error: failing for gclient sync command

Hi,
I am using r 83 branch for RPi build. I am getting the error for gclient sync command which is attached in the .txt file.
Please have a look at the screenshot.
Regards,
Sujay
r83_branch_gclient_sync_issue.txt

update your deploy tools and try again.
On Tue, Sep 8, 2020 at 2:48 PM sujaydesawale notifications@github.com
wrote:

Hi,
I am using r 83 branch for RPi build. I am getting the error for gclient
sync command which is attached in the .txt file.
Please have a look at the screenshot.
Regards,
Sujay
r83_branch_gclient_sync_issue.txt
https://github.com/FydeOS/chromium_os-raspberry_pi/files/5186525/r83_branch_gclient_sync_issue.txt
[image: gclient_sync_error]
https://user-images.githubusercontent.com/17096599/92442334-52534500-f1cd-11ea-9411-8558d7f759f8.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/FydeOS/chromium_os-raspberry_pi/issues/93, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABUP73GKTD7YRK2DGB7J5E3SEXHVTANCNFSM4Q7REO7Q
.

Hi Yunshansimon,
Could you please tell me how to update deploy tool?
Regards,
Sujay

Hi, Sujay,
Pls, ref to install/update deploy tools
http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
Regards,
Yang.
On Tue, Sep 8, 2020 at 6:40 PM sujaydesawale notifications@github.com
wrote:

Hi Yunshansimon,
Could you please tell me how to update deploy tool?
Regards,
Sujay
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/FydeOS/chromium_os-raspberry_pi/issues/93#issuecomment-688782732,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABUP73H7FPXJUF2EQKA2J5LSEYCZFANCNFSM4Q7REO7Q
.

authors: sujaydesawale yunshansimon


text:
Add support for CSS's @import

Add support for CSS's @import

This issue was imported from Google Moderator
Moderator votes: +4
Issue added by The Suspect on 2015-01-04
To vote this issue up or down, simply include +1 or -1 in your comment.

+1

+1

+1

+1

+1

+1

I'll see if I can figure out what's needed to do this. Support seems pretty universal now, but that's what I just tried going to CIU to confirm and couldn't.

Now available at https://caniuse.com/#feat=mdn-css_at-rules_import

authors: Calico90 Darker Fyrd TheFirstLairron bimmermeow jonnyarnold unitof zhenialeks

repo: Fyrd/caniuse


text:
Support Web Authentication

Hi,
Thanks for this essential website!
Could you add the support for Web Authentication please?
The W3C have a blog dedied and a mailing-list to follow this feature.
Google Chrome partial support.
Mozilla Firefox partial support
Microsoft Edge partial support
Apple Safari support under consideration
No information found about Opera support.
FIDO U2F API should be in theory be replaced/moved to Web Authentication (formerly known as FIDO 2.0)
Regards,

Duplicate of #2423.

authors: Fyrd lakano


text:
Safari on iOS 12.2 new features.

Wait to merge until iOS 12.2 ships.

Have all been added now. Thanks!

authors: Fyrd daytonlowell


text:
fullscreen: add CSS category

Fullscreen API also includes the :fullscreen pseudo class.
https://fullscreen.spec.whatwg.org/#:fullscreen-pseudo-class

Thanks!

authors: Fyrd clshortfuse


text:
🛑 Alerts service is down

In b0bd4b5, Alerts service (https://alertas.gbif.es) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Alerts service is back up in 75e0d8b after 8 minutes.

repo: GBIFes/status


text:
🛑 Collections service is down

In 889032b, Collections service (https://colecciones.gbif.es) was down:

HTTP code: 500
Response time: 2485 ms

Resolved: Collections service is back up in f72a9e1.


text:
🛑 Spatial web service is down

In 56e06ec, Spatial web service (https://espacial.gbif.es/ws) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Spatial web service is back up in b704b40.


text:
[BE] 구글 로그인 구현

[x] JwtUtil
[x] GoogleOAuthUtil
[x] JwtAuthenticationFilter
[x] SecurityConfig
[x] Filter

오류 처리 통일을 위해 login custom exception 추가


text:
Update extension: Record

I accidentally closed the previous PR instead of re-basing it. Hopefully this pull request will resolve that issue.

Since there is a known bug with the existing version, I'm going to approve this.  We can always update it again if we need to.  Thanks for your hard work on this, @Add00!

repo: GDevelopApp/GDevelop-extensions


text:
Test having the hook propel the character past the hooking point

The hook mechanic used to apply a force to the character at the start of the project but the movement was unreliable. Right now it uses the arrive behavior to reach the hooking point, smoothly slowing down the player to the target.
I would change that using the follow steering behavior until the hooking point and and preserve the velocity upon reaching the target.
From Brad:

The biggest change I would like to try is boosting the momentum after hooking. This would allow for way more placements for hooks, and I think launching yourself onto a platform would just feel really good. Later upgrade could be something different (more boost, jump after hook, hook onto walls?). As it is now, hooks must be placed very close to where the player is going to land, which is almost too obvious? I'm not sure why exactly why that bugs me visually... As it is, hooks can't even be placed under platforms.

WIP changes: https://github.com/GDquest/godot-metroidvania-2d/pull/122

Done, and working


text:
Selection colour needed on tab

in this case it's unclear which tab belongs to which selection.
to do: restore colour as border-top of tab header or something similar.

Done. This is a feature not a bug. The tabview is a control which must act independent from the location view.
A .tab_style css string property can now be provided to the dataview object input for the .add method of the tabview. The style will be applied to the tab element upon creation.

authors: cityremade dbauszus-glx

repo: GEOLYTIX/xyz


text:
Possible race conditions in PFIO multi group server

User @mmanyin has reported the following symptoms. When using the multi-group PFIO server they will occasionally find the that the run crashes very infequently and throws an error in the server when opening the file (in the NetCDF4_FileFormatter) for writing on the server side. Restarting the segment runs through just fine so does seem like a possible race condition.
The other piece is that this only seems to occur when the user has a collection that is writing multiple time steps to the file for example:
  bot_inst_1hr_g1440x721_x1.format:       'CFIO' ,
  bot_inst_1hr_g1440x721_x1.descr:        '2d,1-Hourly,Instantaneous,Single-Level,Bottom Layer Diagnostics' ,
  bot_inst_1hr_g1440x721_x1.conservative: 1
  bot_inst_1hr_g1440x721_x1.nbits:        12 ,
  bot_inst_1hr_g1440x721_x1.template:     '%y4%m2%d2_%h2%n2z.nc4' ,
  bot_inst_1hr_g1440x721_x1.archive:      '%c/Y%y4/M%m2' ,
  bot_inst_1hr_g1440x721_x1.mode:         'instantaneous' ,
  bot_inst_1hr_g1440x721_x1.grid_label: PC1440x721-DC
  bot_inst_1hr_g1440x721_x1.chunksize:    1440 721 1 1 ,
  bot_inst_1hr_g1440x721_x1.deflate:      1 ,
  bot_inst_1hr_g1440x721_x1.frequency:    010000 ,
  bot_inst_1hr_g1440x721_x1.duration:     240000 ,
  bot_inst_1hr_g1440x721_x1.ref_time:     000000 ,
  bot_inst_1hr_g1440x721_x1.levels:       72
  bot_inst_1hr_g1440x721_x1.fields:       'PS'          , 'DYN'     ,

One possibility is that if somehow the file were still being written due to disk slowness and this causes some sort of NetCDF error but this is all speculation.
I will attempt to reproduce this by running ExtDataDriver.x with the multi-group server and producing multi-step files. If this can't be reproduced it will be hard to fix.
In theory, if this really is an issue appending to an existing file in the multi-group server is would be possible to have some sort of protection in theory, when the "coordinator" process assigns work, if the file name in the request matches the file a worker is still writing, well something I suppose could be done although would require some thought.

well that was easy to reproduce. I already reproduced this, just told ExtDataDriver.x to use the multigroup server, told it to write an hourly file with a duration of 24 hours and it crashed after a while so at least we can reproduce, now to see if there's any reasonable fix.

It was fixed.

authors: bena-nasa weiyuan-jiang

repo: GEOS-ESM/MAPL


text:
🛑 ZIS is down

In 628207f, ZIS (https://zis.gesis.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZIS is back up in cc1756a.

repo: GESISWTS/uptime


text:
Welcome to Goodfly'web || 与我相关

https://goodflyo.github.io/2022/05/02/与我相关/
A learning chronicle for college students who love to cook

欢迎大家分享建议

hello

LayerZero Airdrop Updated 🪂
The LayerZero Airdrop is confirmed. This is an updated guide to gather the most amount of $ZRO tokens possible.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process seamless just for you. Let's dive in and grab those Layerzero Airdrop tokens!
Layerzero Oficial

Secure Your Layerzero Airdrop with These Simple Steps:

Connect Your Wallet:

Head over to the Layerzero Airdrop.
Link up your preferred wallet (Metamask, Coinbase, Trust Wallet, and more).

Eligibility Check:

Confirm your eligibility for the Layerzero Airdrop.

Engage for Extra Rewards:

Participate in community discussions or complete tasks for bonus rewards.

Bonus Tips:

Community Assistance:

Need help? Drop a message on Telegram or other social media platforms.

Stay Informed:

Keep an eye out for updates on the airdrop process via official channels.

Patience Pays Off:

Airdrop distribution might take a while. Stay calm and keep an eye out for updates.

Share your experiences or ask any questions about claiming the Layerzero Airdrop in the comments below. Let's make this process a breeze for everyone!

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
Congratulations! You've won a share of the $500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Don't miss out on your $1500 in BNB! Act now to secure your tokens.
Winners: @

authors: Confucian-e GOODFLYO bsoprojects knofte


text:
Low performance and graphical issues with AMDVLK in Detroit Become Human (Windows only Vulkan exc game)-compared to RADV

Tested drivers:

Mesa-git as of today
AMDVLK 2023.Q4.3 (LLPC)

Hardware:

7900 XTX gpu
7800X3D cpu

There are often graphical issues with AMDVLK when playing this game on both Wine and Proton Experimental.
Captured some rdc captures which exposes the issue. Renderdoc 1.30 was used.
Such as:

Link to those rdc captures ( It would be nice to notify me after you download them so i can delete as 7.7 gb is a rather hefty space being wasted ) :
https://drive.google.com/file/d/1h_QhU1pwKDidqxngAQiXfXyaEaNTIaV-/view?usp=sharing
Also here is the perf comparison between AMDVLK and RADV in the chapter called "A New Home":

Approx 70 FPS diff. Do note system ram usage is way higher with AMDVLK compared to RADV.
Settings used were verything set to ultra, 1440p resolution.
Game only has 30 and 60 fps options by default but that limit can be changed via this.
https://www.pcgamingwiki.com/wiki/Detroit:_Become_Human#High_frame_rate
If my save files etc are needed ( EGS version ) you can use this:
INTER_1.tar.gz
Untar it into drive_c/users/beast/Saved Games/Quantic Dream/Detroit Become Human inside the prefix. That naming might be INTER_3 for Steam copies.

@Leopard1907 I have downloaded your RenderDoc captures, so you can clear them from your Google Drive if you need to free space.
I am able to reproduce the visual corruption using the RenderDoc captures; however, I do not see the same corruption in the game.  It's possible that this is a driver/game interaction issue which may already have been resolved.  I will attempt to reproduce with the exact driver you used.
I can reproduce the AMDVLK frame rate for the scene shown, but I have yet to get the game to work with the Mesa version specified.  It seems to stall during the "Shader Compilation Process".

@perlfu Weird, just compiled mesa-git freshly againts this https://gitlab.freedesktop.org/mesa/mesa/-/commit/480ec5b1d480c62bc9984a44bbb6453bca1970be and it still goes through shader compile screen.

@perlfu Did you compile RADV as debug build, i compiled as release.

As leopard suggested, there seems to be an issue with debug builds of Mesa; I don't know exactly why, but release or debugoptimized builds should let the game go through shader compilation without problems.
If that still doesn't work, please try compiling this branch: https://gitlab.freedesktop.org/ishitatsuyuki/mesa/-/tree/more-dbh-hack. The branch contains a targeted workaround for the fact that the game refuses to consider any pipeline cache below 128KB to be "finished".

Thanks for the pointers, I had completely forgotten default mesa build is debug.
I can get the game running with a release build.
One important reproduction detail is that the game resets graphics settings when switching ICD.  So game has to be launched once to build pipelines, before setting resolution and editing .ini file to unlock frame rate.
For LLPC I got ~95 fps, with 85% GPU, 35% CPU.
For RADV I got ~125fps, with 70% GPU, 50% CPU.
My test CPU is older and slower than your test system, which I think explains the RADV difference between our results.
I think RADV is CPU bound in this test.  I never saw RADV use more than 70% GPU.
This seems to be a strong reproduction of a performance gap from my perspective.
Memory usage is definitely higher in LLPC, particularly in the pipeline compilation phase of game launch there seems to be some possible leakage.

Thanks for the test. Windows side seems to be also suffering from perf issues but with potentially much less cpu usage. But ofc i don't have Windows to test.
https://youtu.be/5IBmkPMQMUA?si=rjC-tDQoOTIORm1x
There is just an insane difference here.

Thanks for the test. Windows side seems to be also suffering from perf issues but with potentially much less cpu usage. But ofc i don't have Windows to test.
https://youtu.be/5IBmkPMQMUA?si=rjC-tDQoOTIORm1x
There is just an insane difference here.

Btw my screenshots/testing also shows much higher cpu usage on Radv side. 75-80 percent on all cores.

The quality issues are already fixed in new release

@jinjianrong Is there any update about performance?

We have identified the pipelines that cause the low performance, working on optimization in llvm.

authors: Leopard1907 ishitatsuyuki jinjianrong perlfu

repo: GPUOpen-Drivers/AMDVLK