Official Touch Screen and Xorg

[jamesh]

It's possible the new ARM side graphics driver (still in beta) already supports this. I'm going to have a play with it to see what happens.

[John Westlake]

jamesh,

It be incredibly appreciated if you could look into this - we have four CM3 based designs for different companies that could really be expanded with the both internal and external display support - some of these products will be displayed at CES this year,

[jamesh]

I'll take a look but a bit busy - you can of course try it yourself - use raspi-config to enable the experimental graphics driver.

[John Westlake]

Jamesh,

I'm a hardware designer - with practically zero experience of Linux and have little clue where to start.

The trouble I face is that my software guys are pretty lazy and there first excuse is always going to be "it cannot be done" - or even better "its going to cost a lot of money to do that" - so what I need to be prepared for this stone walling is to be able to say - look it can be done, here's the information....

How can we more forward from here?

Not sure if this is any motivation, but we are talking orders orders of multi 10K's of CM3 module...

[jamesh]

I'm going to be looking in to both the new driver, and implementing multiple screen support in the current driver in the new year, but have no timescales. I'll forward your comments to boss to see what sort of schedule he will be happy with - we do have a lot on.

[John Westlake]

Thank you

I'm not sure if this is relevant, but we use the DPI interface driving 800x480 LCD panel with CTP for the internal display (which is "low frame rate video", think menu options / user controls) with the HDMI external display working with faster frame rates - think video display etc.

I would expect this to be a fairly typical setup for the CM3 in "Pro" applications.

We would generate quite a bit of buzz for the CM3, and experience shows that in our small industry sector where we lead others follow - and you can expect follow on "copycat designs" that will basically duplicate our hardware "solution" all good for CM3 sales & at the end of the day for the end consumer and also the RPI community... (not so good for me - but hey)

Recent we had a press day with EISA journalists from all across Europe and I had the opportunity to introduced them to some pending designs and they REALLY loved the idea of releasing "open" RPi based audio hardware - we currently have designs in the lab for 7 different audio brands so there will soon be a delude of CM3 based audio systems - all good for RPi community

https://www.eisa.eu/

https://www.instagram.com/p/BbuDgWbnWmm/

I was in two minds as to how the all important press would see the idea of embedded RPI - wither it would be seen as "amateurish" or whither they would see the benefits to the customer of an open source solution' (the plan is to keep the hardware as open as possible with published APi so customers can install there own audio player if they want a more hands on approach to there "HiFi system which no longer needs to be considered a "closed" black box). It was a pleasant surprise to see that almost all journalists in the room understood the potential of such an open source solution - its good to generate some buzz and excitement in our industry which can be rather elitist and myopic ....

Just saying... we REALLY could do with the dual display support so we can fit LCD's with full GUI on the front panels of the Audio products and help move the "premium" HiFi industry into more GUI based designs... Customers now expect an iPhone type display and UI experience - the CM3 can help us achieve this... but we need to support both an external HDMI display and an internal "local" display.

[jamesh]

I'm not sure about DPI, I know the new graphics driver works with the DSI+HDMI displays, but DPI is something I know nothing about (The Pi supplied LCD display is DSI so we don't use DPI in house).

So I'll need to investigate tomorrow.


Worth noting, we have sold MILLIONS of devices in to industry for embedding in other product - it's just that people rarely advertise it, or let us advertise it!

[John Westlake]

Just to confirm that the new graphics driver works with the DSI+HDMI with independent displays concurrently on each display interface? - if so, this would be brilliant news as my rather limited understanding is that the most difficult task is to enable a second framebuffer in the GPU Driver.

Once the second framer buffer is available then it can be assigned to a physical port (DSI / DPI / HDMI etc) in Xorg. (Again, I stress I'm only a hardware guy so I could be misguided).

Getting DPI working is easier then DSI on the RPi - the DPI is a very simple interface and is the most cost effective "local" display option - for smaller Qtys. DSI is a bag of hurt.

I know that NEC uses CM3 (they have a 8GB version) - I've not seen any other "Mass" commercial product with CM3...

The HiFI industry is dying - partially though its own fault but also due to the advent of Digital which has taken away the ability to optimise the performance of the system - in the days of turntables there was so many "upgrade paths" that would encourage the hobby.

By offering open source "enabled" designs I hope to encourage the sprint of developing software and adding features etc. Sure maybe only 5% of our customer base will experiment but its more about the spirit of the design.

Apparently our press spokesperson knows your Lucy Hattersley so I have no problem passing on any news releases etc. about our designs using the CM3... I think its only good to start showing the world how many devices use the CM3 (RPi) - with Britons current Brexit wows we should be proud of British innovation - and RPI is typical of that very British spirit!

[jamesh]

Just to confirm that the new graphics driver works with the DSI+HDMI with independent displays concurrently on each display interface? - if so, this would be brilliant news as my rather limited understanding is that the most difficult task is to enable a second framebuffer in the GPU Driver.

Once the second framer buffer is available then it can be assigned to a physical port (DSI / DPI / HDMI etc) in Xorg. (Again, I stress I'm only a hardware guy so I could be misguided).

Getting DPI working is easier then DSI on the RPi - the DPI is a very simple interface and is the most cost effective "local" display option - for smaller Qtys. DSI is a bag of hurt.

I don;t specifically know what goes on yet, will be trying it today. I don't think you get two framebuffers, but one that can be spread over two displays, but again, I need to check.

I also need to check how this would interact with DPI, since I don't believe this has ever been tried - the guy who wrote the VC4 driver used the DSI
display.

[John Westlake]

James,

Thanks for the reply, waiting for your update

[jamesh]

James,

Thanks for the reply, waiting for your update

Going to be the new year before I can look at this. In general we are going to need to do a lot of work to get multiple display up and running using the standard graphics driver, so I don't think it is going to be quick from that perspective, but using the new driver may work fairly quickly, but its does have issues. So, again, not a quick fix.

[John Westlake]

What can we do to push this request up the "To-Do Fire Fighting" list at RPi?

If you have an *reasonably priced external consultant - dependent on cost I might be able to help fund the Driver development (for public released)?

This thread was first posted back in September 2015, so I think we need to get this request somehow more "official" otherwise it will just stay on the bottom of an ever growing I'm sure "to-do" list.

* Is there ever such a creature?

Its a shame, as we could have had units shown at this years CES - If we had reasonable certainty on timeframes and that it was possible, we could have units shown with internal displays (but external HDMI not enabled)... no one would be any the wiser at CES...

[jamesh]

It's certainly on our list, and fairly high priority. We have limited resource*, and this code is closed source, so it has to be us that does it. I am not the arbiter of what gets done though, but the guy who is was talking specifically about this a couple of days ago. I expect to be working on it in the new year. However, I am not an expert on this stuff from a Linux pov, so it probably not going to be quick. I'll be putting together some sort of spec to determine what customers actually want first.

*And we do have a lot of projects on.

[John Westlake]

We can support you with DPI enabled hardware - with the panel working in single display mode so you have all the DPI panel settings and config files.

Our basic requirement is to have to have two independent displays operational - these displays can be different resolutions / colour bit depth.

No problem to open source the DPI panel hardware connections etc. its a very simple interface. DPI is not possible with some versions of RPi as a few GPIO are used for local hardware functions (IIRC, such as LAN Reset or some such on RPi 2).

With two independent displays they can be either s single xSession with extended desktop - or two xSession for complete UI Independence (I guess this would be used when you would want independent touch screen / mouse operation / UI).

For where we would like to go with our CM3 based designs (our clients really want local user / menu UI and external independent display support) - I can help with contacts within the Linux community - Red Hat is just down the road here so there is a local pool of talent that I could reach out to - if I know whats required.

Lets arrange to get hardware to you "next year"

I believe the hard part is enabling the second GPU frame buffer in the driver - then assigning a physical display interface (HDMI, DSI, DPI etc). is a simple task in Xorg

[John Westlake]

James,

Just a New Years "ping" to keep the pressure on - we are very keen for a dual independent display solution.

[jamesh]

James,

Just a New Years "ping" to keep the pressure on - we are very keen for a dual independent display solution.

Been off sick since Xmas, but am thinking about it. Fortunately, we do have an internal requirement for this, so is fairly certain to be done.

[John Westlake]

Hope your feeling better - my lead engineer has also been off - at the worst possible time with CES...

About the run the first prototype PCB's - so it be great if you can get the second display channel going. the PCB's have a DPI RGB interface connector for "internal display panel" - so hoping it will be used in the end

[jamesh]

I'M back in the office, and have started looking at this. I suspect is a long job, at least a month.

[John Westlake]

Well thats to be expect - its hard to predicate how long something like this will take - it will be done when its done!

As a designer, nothing irritates me more then when people ask me to developed a new design then ask how long it will take - if I knew, then I'd not have to develop anything because it would be already conceived!

If you need any help - just ping me, we might be able to help as in the area I'm surrounded by RedHat programmers.

[jamesh]

Well thats to be expect - its hard to predicate how long something like this will take - it will be done when its done!

As a designer, nothing irritates me more then when people ask me to developed a new design then ask how long it will take - if I knew, then I'd not have to develop anything because it would be already conceived!

If you need any help - just ping me, we might be able to help as in the area I'm surrounded by RedHat programmers.

It's a combination of things that needs to be done - I need to update the GPU firmware to handle multiple framebuffers, since it was original written with only one in mind, then expose to Linux and update the Linux FB driver to cope with those multiple underlying framebuffers.

It's not my only task at the moment, so isn't getting 100% of my time.

[Tommyten]

Are there any news @jamesh?

[Tommyten]

I've actually gotten it to work using the experimental drivers. My only problem now is that the Touchscreen mirrors the top left corner of the HDMI Display. If I use xrandr to position the DSI Display below the HDMI the DSI still mirrors the top left corner of the HDMI Display, but doesnt mirror the mouse. To get the mouse cursor on the DSI Display I need to move the cursor down to the DSI Display just like a dual monitor setup would work. Just that it always Displays the top left corner of the main screen.
I need to run a Processing Sketch fullscreen on both screens, either using the span option or with two sketches, one for each display. Any way I can get the touchscreen to not mirror the HDMI Display?

[John Westlake]

Hi James,

Do you have any update? Keen for news

[John Westlake]

James,

A late May "Ping" to keep the pressure on, has there been any further development? - we are still very keen for a dual independent display solution....

[jamesh]

OK, I have got multiple frame buffer working (end of last week). I now have a FB0 for the HDMI and FB1 for an attached DSI LCD panel (will probably work with DPI as well). You can switch consoles, use fbi to load to the other FB, but not managed to get X to have an extended desktop yet.

Lots of code changes - will have to test the living daylights out of it. My testing has gone pretty well so far, but I an concerned about regressions in areas I've missed i.e. stuff people have done stops working. No idea how long that will take. Might be able to release a test version at some point, hopefully soon. I've got some other work on at the moment so not on this 100%