00:00 <akaWolf0> clover[m]: offtopic https://i.kym-cdn.com/photos/images/facebook/001/253/061/84f.jpg

00:45 <Anonymous> hi

00:47 <steev> hello

00:48 <Anonymous> espeak spanish

00:50 <steev> i do not, i'm only english and bad english

00:52 <Anonymous> im new

00:52 <Anonymous> in all this

01:03 <steev> welcome to the club :)

01:04 <Anonymous> thanks i want to learn

01:08 <Anonymous> what is your favorite system

21:42 <steev> bamse: not that you can do anything about it i don't think, but whatever lenovo pushed for the venus 5.2 firmware to linux-firmware doesn't play nice on the c630

21:42 <steev> s/lenovo/qualcomm/

21:45 <bamse> steev: doesn't it just fail the signature check?

21:46 <steev> srinik: this is audio on next, something odd is happening https://usercontent.irccloud-cdn.com/file/6eEfz6LX/69335193025__E6190353-6D5E-4517-A30B-5BE53A70DB29.mp4

21:46 <steev> bamse: possibly - error -22

21:48 <bamse> steev: you need to point it at a properly signed vss850.mbn (or whatever it's named...)...pretty sure it eats a firmware-name in dt

21:48 <steev> hm, will have to look, it seems like if venus.mdt exists, it tries that

21:49 <steev> which it does in linux-firmware, is a symlink to "venus.mbn"

21:49 <steev> ah, we don't have the firmware name in dt

21:49 <bamse> then it will fall back to venus-<version>.mdt

21:50 <steev> will try adding it, and if it works, submit it

21:50 <bamse> :)

21:51 <steev> and still have to revert the dp patch in order to get vidya :(

21:52 <steev> though, those patches are still way in flux i guess

21:52 <bamse> iiuc we'll get the dp part in 6.3...

21:52 <bamse> but the battery driver is still in flux

21:57 <steev> yeah, don't they want it to be mfd?

21:57 <bamse> well...there was a concern that the drm guys might want it to be an mfd

21:58 <steev> the drm guys are weird

21:58 <bamse> well, they might be...but they haven't voiced any concerns

21:58 <bamse> the issue is concerns about them possibly not liking it

21:59 <bamse> so it's possible to do...but it adds a lot of complexity...which seems unnecessary unless it's actually required

21:59 <bamse> and it's going to cost us ~2kb of ram...for nothing

21:59 <steev> f that

21:59 <steev> i need as much of my 8gb as i can get

22:00 <bamse> isn't it ~7?

22:02 <steev> indeed it does work

22:02 <bamse> cool

22:03 <bamse> but what's up with your dp? or it's just black so you don't know?

22:03 <steev> display-controller ends up deferred

22:03 <bamse> forever?

22:03 <steev> yes

22:04 <steev> but reverting just the dp portion, it works fine

22:04 <steev> well, i mean, no dp, but still

22:04 <bamse> just the dp-link in dts? or the whole thing?

22:05 <steev> i reverted the entirety of "arm64: dts: qcom: c630: Add DisplayPort controller" but, just setting both mdss_dp to status=disabled and adding in status=disabled inside port@1 also works

22:06 <steev> wait a second

22:06 <steev> oh it was just artifacting

22:07 <steev> i thought somehow maybe it had not applied cleanly and i fucked it up, but i didn't

22:07 <steev> and it didn't

22:07 <bamse> let's make a rebase once the dp code is pulled in

22:07 <steev> that works

22:07 <steev> i was just trying -next since the efi patch was in and wanted to see what it looked like