03:53 <xtex[m]> What's the relationship between qcom mdp, mdss, msm fb, and msm hdmi?

03:53 <xtex[m]> They are almost the same things in my eyes.

05:36 <aka_[m]> Mdss is like entire block and others sounds like subblocks, excluding msm fb which is just driver meant for handling framebuffer device

05:41 <xtex[m]> Thanks. I see bothof a DSI panel dev and a HDMI device were added in the xiaomi-aries kernel. Are they different? there are only one screen on the phone.

05:42 <xtex[m]> Do I still need to make a FB node after rewriting arch/arm/mach-msm/ code from 3.x kernel in device-tree style? or just add a GPU node?

05:44 <aka_[m]> No, on mainline fb is initialized by mdp driver

05:44 <aka_[m]> I guess apq8064(that's mi 2 soc right? ) have display subsystem defined?

05:45 <aka_[m]> You just enable and configure functionality you need

05:45 <xtex[m]> Thanks. Yes I think, as I has seen it in dt binding.

05:45 <xtex[m]> s/has/have/

06:33 <xtex[m]> does qcom,mdss affect the working of kernel? I found that apq8064 dtsi in mainline kernels places all dsi, gpu, mdp nodes under the soc node, without wrapping with a mdss node.

07:25 <aka_[m]> xtex 🅥: tbh I have no exact idea of_node in drivers can probe children of nodes.

07:25 <aka_[m]> This probably depends on driver structure and apq8064 uses mdp4 while newer have mdp5 which might have some different probing order

07:25 <aka_[m]> lumag: as maintainer of msm_drm is your best source of knowledge

07:38 <xtex[m]> thx

13:30 <DylanVanAssche> I'm using libqrtr from linux-msm to mock a QRTR service. Receiving QMI messages works, but as soon as I try to reply to them I get 'ERROR libqrtr: sendto(): Connection reset by peer'. Libqmi client does not show anything regarding incoming message, so I think the socket is immediately closed as soon as I try to send?

14:52 <bamse> DylanVanAssche: the one reason that comes to mind is if the node id you pass is invalid

14:53 <bamse> DylanVanAssche: yeah, kernel code says if the node isn't found you get ECONNRESET...and that seems to be the only source of that (unless there's something in the socket stack)

14:59 <DylanVanAssche> bamseI use the same node ID as the one I received from the message of the client. I'm the QMI server here.

14:59 <DylanVanAssche> I can push my code to some git repo if you want

15:02 <bamse> DylanVanAssche: sure, i can take a look

15:03 <DylanVanAssche> bamseI pushed it to https://codeberg.org/DylanVanAssche/libssc/src/branch/fake-sensors/mocking/ssc-server#L112-L133

15:04 <DylanVanAssche> This is a Python thing though, I used the example `qrtr.py` from the repo as basis. All functions worked fined, except the sendto, I fail to make that one working

15:07 <bamse> cool, been a long time since i saw someone playing qrtr in python

15:07 <bamse> looks reasonable to me though...what is the value of your node?

15:08 <DylanVanAssche> 1 and 0. If I use `qrtr-lookup`, it works though

15:08 <DylanVanAssche> node = 1, port = 0

15:09 <bamse> port 0 doesn't sound right

15:09 <DylanVanAssche> port = 16535 *

15:09 <bamse> better :)

15:10 <DylanVanAssche> Yeah that's with qrtr-lookup, with the ssc-server mocking, I have node = 0 and port = 1...

15:12 <bamse> what are you saying, qrtr-lookup shows your server as node = 0 port 1something?

15:14 <bamse> per convention, linux (on application cpu) is node 1... modem is 0

15:16 <DylanVanAssche> qrtr-lookup shows with node = 1 and port = 16535. In the Python code, I get from the receiving message node = 0 and port = 1. If I manually put `node = c_int(1)`, The reset error goes away, so something weird is happening on passing the values. Now it times out to reply, so another thing to debug now :)

15:17 <bamse> DylanVanAssche: and you don't have a modem running?

15:18 <DylanVanAssche> bamseNo this on x86

15:18 <bamse> DylanVanAssche: well regardless, you're not receiving that message from node 0 port 1, so there's something wrong there

15:18 <bamse> DylanVanAssche: and when you then try to send back to node 0, there's no such node and you get your error

15:21 <DylanVanAssche> bamseI'm trying to imitate the modem for mocking, so I should send the reply back to node 1 right? As the server is the modem

15:21 <bamse> DylanVanAssche: your _receive_msg() should return something like 1, 163xx

15:23 <bamse> DylanVanAssche: you are the server, as you do qrtr_open() you get a port reserved on the local node (1 unless you change that), you then register this with the nameserver using new_server()...at this time it shows up in qrtr-lookup (which just asks the nameserver)... when your client creats a socket (on this same linux instance) it too will be associated with node 1, and unless you do something specifc will be dynamically

15:23 <z3ntu> bryanodonoghue: Do you have an rb3gen2 by now? The camss patchset for it (sc7280) is a bit broken and the Qualcomm person who sent it is not fixing it :D

15:24 <bamse> DylanVanAssche: so, as your server receives a message it should come from that client at node 1, port 163xy...you "process" your message and need to send it back to that same port (to find it's way back to the same socket)

15:27 <bryanodonoghue> i have a rb3gen2 in a box never powered on

15:27 <bryanodonoghue> which counts for aprox 99% of the kudos

15:29 <bryanodonoghue> I think the qcom team intends to submit another version

15:29 <bryanodonoghue> did they provide a dts for the sensor too ?

15:30 <bryanodonoghue> z3ntu broken how ?

15:31 <z3ntu> bryanodonoghue: broken like this: https://lore.kernel.org/linux-arm-msm/D2GUG0KGQNHX.3AITI7PGV3KW3@fairphone.com/

15:31 <z3ntu> yes dts parts are also in their patchset

15:32 <bryanodonoghue> oh - I didn't see that in my inbox

16:14 <DylanVanAssche> bamseI just checked, the incoming message comes from node 1 at port 0 to the server. That is not right then? The client is libqmi-glib.

16:27 <bamse> DylanVanAssche: it's been a while since i dug into the very details of qrtr and qmi, but that doesn't sounds right...node 1 sounds good, and i don't know why you get that error message... port 0 doesn't sound right, but i don't remember if it's reserved or not

16:28 <bamse> DylanVanAssche: as far as i can see, the ECONNRESET only comes if the server's node id != recipient's node id, and the recipient's node id is unknown to us...

16:31 <DylanVanAssche> bamseOkay, will dig further into it. I really want to have this working to add some unittests to libssc and iio-sensor-proxy for the sensors. Testing them on hardware each time is not great :)

16:34 <DylanVanAssche> bamseAh no, I missed it, the incoming message send by libqmi comes from node 0 with port 1. So the server receives a message from node 0 @ port 1. But you said it has to be node 1 (Linux) as the modem is always node 0 right?

16:36 <DylanVanAssche> [dylan@desktop src]$ ./qrtr-lookup

16:36 <DylanVanAssche> Service Version Instance Node Port

16:36 <DylanVanAssche> 400 1 0 1 16385 Snapdragon Sensor Core service

16:36 <DylanVanAssche> QRTR lookup ^^^

16:43 <bamse> DylanVanAssche: net/qrtr/af_qrtr.c has "static unsigned int qrtr_local_nid = 1;" so unless you change that (i think there's a tool qrtr-cfg?) node id for all your services and clients are expected to be 1

16:44 <bamse> DylanVanAssche: your idea about making this testable "offline" is a good idea, i've used it plenty of times...

18:37 <DylanVanAssche> bamse: ah will look at qrtr-cfg. Testing is needed :p

20:54 <bamse> DylanVanAssche: you only need qrtr-cfg to change that default "localhost" from 1 to something else...so it really shouldn't be needed