Confusion in channel/device/screens identification ?

[vinz6751]

Could there be a mixup/confusion in channel/device screens ?
In chan_alloc it is said "For most devices (all but files): the channel is always the same number as the device".
So ok, channel 0 is a t_dev_chan with number CDEV_CONSOLE (=0). No problem with that.

But that t_dev_chan is backed by a t_txt_device . The K has 2, the U has one. These text devices have a t_txt_device.number of their own which should be independent from the t_dev_chan.number as they are different beasts.

The fact is, it's not: in cli_txt_screen_get we use the result of sys_chan_device as t_txt_device.number. That is, if you give different devices ids to the A2560K channel A, channel B and A2560U channel C, it stops working.
Also because of that there is the need of the "chan_swap" trick.

I think that's prone to confusion (well it confuses me, granted I can be easy to confuse !). I think we should be using enum values e.g. CDEV_CONSOLE, TXT_SCREEN_A2560U rather than just "0" to make clear what we're talking about, until (maybe) we bring some more clarify there.

[pweingar]

Yeah... I can see this. Some of this could use rework, maybe. The separate text driver aspect was pretty late in the development of MCP, and the chan_swap business was very late. Some of the comments in the code may be old, and I could have made some mistakes in the current code (shocking, I know!).

One thing that may help clarify, however... the text screen ID was meant to relate to the DVI port of the machine. Think of them like screen numbers in X11. Screen 0 would be the combined text and graphics display (the main screen on FMX, the U models, and Channel B on the K and GenX), and screen 1 would be the text-only screen (the EVID card, and Channel A). The ID wasn't meant to be driver specific. I'm not sure if that's how you were thinking about the ID... but your comments suggest that the U main screen might be #2, for instance.