New QLC+ ... touchscreen support

All the topics related to QLC+ on the Raspberry Pi
Frank

Hi Massimo,

I'm understanding your doubt. To support your development (testing, to gain experience and so on) I ordered the same one as you (thank you for the link!).

But finally - I'm quite sure - every small display will be good enough to help operating a finalized light show on the RPi, because only a few touches are necessary to do so...

Yesterday I tested the procedure of loading the necessary drivers (and tools) to convert the very new Raspbian (2015-01-31) into a standalone RPi. I connected it with a 3,2" TFT ( or ).

They are 320x240 too and are working quite good.

Firstly I found only sorrowful messages concerning these types of displays (they are called WaveShare SpotPear), because they came with a special img-file and no upgrade procedure worked for them. Unbelievable... Only a few features were integrated into that img-file. Quite useless...

But yesterday I found these very detailed tutorials ( and ) and the success came really only a few minutes later!

A very interesting information is, that the used driver () includes a wide range of supported TFTs!

And if it should be possible for you to go this way, I think it will be a very big success of your QLC+ on RPi. If it is possible for you to preserve that generic approach, it will be quite simple for a lot of interested guys to complete their QLC+ controllers...

As you can see / feel, I'm very enthusiastic and full of hope for this extension of your very nice development.

Thank you in advance
Frank
Frank

Hi Massimo,

as a next step I successfully connected an other TFT touch screen to the RPi (). It's that one I mentioned before...

I wouldn't mention this little success if it had been as simple as described in the tutorial I referred above (). There was specified to only exchange the name of the TFT inside two "command lines" of the __/etc/modules__ file. I won't describe the necessary changes here because it's not the right place for it, but I could deliver more details if they are useful for you...

That tutorial (plus some important changes for other types of TFT) helps really to equip a RPi with such a small "head".

On the other hand I know, that this isn't the solution for you to implement support for (any) TFT touch screen in relation with QLC+ on RPi, but may be there are "hidden" hints for easier finding a solution.

Many thanks for any remark.

Frank
Frank

Hi Massimo,

the 3,5" (480x320) touch screen (we ordered "together") arrived at me today...

I think - if not happened already - your part will arrive at you soon.

Hopefully you are glad to hear these "busy" news too...?

Thank you in advance
Frank
Massimo Callegari

Hi Frank, mine hasn't arrived yet. So I guess it will in a few days.
I'll keep you posted when I get onto it.

Cheers
austinpthomas
Posts: 4
Joined: Tue Apr 14, 2015 12:03 am
Real Name: Austin Thomas

I'm using a pi 2 and I'm trying to get a 7" touchscreen installed (http://www.sainsmart.com/7-inch-tft-lcd ... a-2av.html), but I can't get any results from the command lsusb, it says the command doesn't exist. Any suggestions? I'm running the latest image which was just put out yesterday. Thanks! (This is a really nice screen btw!)
User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

austinpthomas wrote:I'm using a pi 2 and I'm trying to get a 7" touchscreen installed (http://www.sainsmart.com/7-inch-tft-lcd ... a-2av.html), but I can't get any results from the command lsusb, it says the command doesn't exist. Any suggestions? I'm running the latest image which was just put out yesterday. Thanks! (This is a really nice screen btw!)
apt-get install usbutils :?:
austinpthomas
Posts: 4
Joined: Tue Apr 14, 2015 12:03 am
Real Name: Austin Thomas

Thanks for the quick response! I had tried that before but it wouldn't install. I get this "no installation candidate." I am connected to the internet and can ping out if that helps? Thanks!

Image
austinpthomas
Posts: 4
Joined: Tue Apr 14, 2015 12:03 am
Real Name: Austin Thomas

I figured it out! I did apt-get update, then did apt-install usbutils, and now lsusb works!
austinpthomas
Posts: 4
Joined: Tue Apr 14, 2015 12:03 am
Real Name: Austin Thomas

I'm having trouble getting my eGalax Touch screen working, it shows up with lsusb and shows up as an input. Any advice or direction? Thanks in advance!
User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

austinpthomas wrote:I'm having trouble getting my eGalax Touch screen working, it shows up with lsusb and shows up as an input. Any advice or direction? Thanks in advance!
This topic was opened to discuss another kind of touchscreen, connected via SPI and using a particular Linux driver.
Your case is different, as the display is basically standard HDMI + a USB connection to send back the touchscreen information.

Now if you want us to help you, you need at least to tell us on which device the touchscreen is mapped. It should be something like "/dev/input/eventX"
Once you identify the right device doing

Code: Select all

cat /dev/input/eventX
Should produce an output when you touch the screen.
Then you need to tell QLC+ (basically Qt) to listen to that interface.
Try something like this

Code: Select all

service qlcplus stop
export TSLIB_TSDEVICE=/dev/input/eventX
qlcplus -w -p
Further information here: http://doc.qt.io/qt-5/embedded-linux.html
jsmain
Posts: 6
Joined: Tue Apr 21, 2015 5:44 pm
Real Name: Jeff Main

User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Good news everyone !

After a 3 months odyssey with the italian posts (which ended up in me receiving a broken display!) I've finally being able to bring one 3.5" 480x320 TFT at home.
This is the item: http://www.aliexpress.com/snapshot/6696212639.html
It is similar to all the ones we've discussed before in this thread (Watterot, Adafruit, etc..) but it's incredibly cheap...and it just works fine !
I do not suggest to purchase a display with a resolution lower than 480x320. You would have serious problems in designing a Virtual Console on lower resolutions.

The good news is that the latest QLC+RPI image (20150412) has all the necessary software to make them work.
Thanks to the inclusion of the fbtft driver in the standard linux kernel: https://github.com/notro/fbtft
More or less, the supported displays are listed here: https://github.com/notro/fbtft/wiki/LCD-Modules

All the chinese clones marked as "Raspberry Pi LCD/TFT touchscreen" should work, just make sure they use SPI for the display and a compatible driver for the touchscreen surface.
Mine uses the XPT2046 touchscreen controller.

So, I'm proud to say QLC+ on the Raspberry Pi supports another piace to make a fully standalone controller with touchscreen support.
Here's a picture of mine running:
IMG_0883-2.jpg
And here's the instructions to make it work:

Edit 'config.txt' file in the vfat partition and add this line at the end of the file:

Code: Select all

dtoverlay=piscreen,speed=16000000,rotate=90
if 'piscreen' doesn't work for you (e.g. you don't see any image on the TFT, the possible values are:

Code: Select all

hy28a, hy28b, mz61581, piscreen, pitft28-resistive (former pitft), rpi-display, tinylcd35
Also, you might wanna play with the 'rotate' parameter.
(optional) If you want to see the boot messages as well, edit the 'cmdline.txt' file and add this at the end of the kernel parameters:

Code: Select all

fbcon=map:10
(optional)Boot the RPi, login via SSH and test the screen with this command:

Code: Select all

cp /dev/urandom /dev/fb1
Finally, configure QLC+ to start on the new display.
Edit the /etc/init.d/qlcplus file and add the following at the beginning of the line starting with QLCPLUS_OPTS=" ... ":

Code: Select all

-platform linuxfb:fb=/dev/fb1 -plugin evdevtouch:invertx
Enjoy !
User avatar
Frank
Posts: 66
Joined: Tue Jun 09, 2015 7:34 am
Real Name: Frank

mcallegari wrote:Good news everyone !
Hi Massimo,

thank you so much for the new features implemented in the meantime by yourself!

First of all I want to confirm, that the touchscreen we discussed before (480 x 320) is working straightaway... (using your description). That's really a big success!

When I tested the Watterott display (320 x 240) - using 'rpi-display' for dtoverlay - the display was showing the virtual console, but the touch functionality didn't work correctly!

Another touchscreen called Waveshare 3.2" is supported by the FBTFT driver usually, but its "name" wasn't mentioned by you (hy28a, hy28b, mz61581, piscreen, pitft28-resistive (former pitft), rpi-display, tinylcd35). How did you discover the types of TFTs that should work? If one looks into the driver source file (https://github.com/notro/fbtft/blob/mas ... t_device.c) a lot of TFTs are "mentioned" inside the code, but are they all supported in reality? Is it only necessary to choose the "right name" or is there another adaptation required that could be done only by you...?

---

As I'd seen in other discussions regarding the Rpi together with a touchscreen, there was used almost everywhere a calibration tool (software) for the touch functionality, that delivered some numbers (parameters) when using it (... the numbers had to be applied inside a driver configuration or so...).

Also concerning the directions of the touch function (where are the min and max for x- and y-axis, for outputting the "right" corner when touching it) there should be some parameters for that driver configuration (similarly to the rotation parameter of the TFT display) ...

Another question - sorry for the missing knowledge of mine -
Is there a possibility to reduce the resolution of the hdmi output (maybe VGA or so), so that the shown virtual console could be more useable at the small touchscreen??? Or has the "mirrored" display content always "full hd" resolution? (... and is therefore always only the "upper left corner" of the full hd internal representation...?).

Thank you in advance
Frank


PS: Date and time at the header aren't true! I wrote my remarks and questions today, June 09...
User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Frank...so many questions !!
Frank wrote:How did you discover the types of TFTs that should work?
Please read my post carefully. I've shared the link of the displays supported by FBTFT: https://github.com/notro/fbtft/wiki/LCD-Modules
In general, I suggest to read all the pages of the FBTFT project: https://github.com/notro/fbtft/wiki
Frank wrote:Is it only necessary to choose the "right name" or is there another adaptation required that could be done only by you...?
QLC+ has nothing to do with these displays. The variables here are the FBTFT driver and the Qt 5 libraries. (almost) Everything is documented online.

I posted the instructions for what I have in my hands. Obviously I don't know how to get to work every LCD display that exists on earth.
You need to start from my post and continue from there.
Also keep in mind that the FBTFT driver supports a number of chipsets. If your display has a different chipset, it might not be supported, so you need to ask who sold it how to make it work on the Raspberry Pi.
If they propose custom drivers, then good luck. It might be a true pain.
Frank wrote:As I'd seen in other discussions regarding the Rpi together with a touchscreen, there was used almost everywhere a calibration tool (software) for the touch functionality, that delivered some numbers (parameters) when using it (... the numbers had to be applied inside a driver configuration or so...).
Read carefully those discussions, as they might be using a library called 'libts'. In this case I haven't used it but instead Qt receives the touchscreen data from evdev.
Frank wrote:Also concerning the directions of the touch function (where are the min and max for x- and y-axis, for outputting the "right" corner when touching it) there should be some parameters for that driver configuration (similarly to the rotation parameter of the TFT display) ...
See above. It's all documented online. Just search with Google: https://github.com/notro/fbtft/wiki/Touchpanel
Frank wrote:Is there a possibility to reduce the resolution of the hdmi output (maybe VGA or so), so that the shown virtual console could be more useable at the small touchscreen??? Or has the "mirrored" display content always "full hd" resolution? (... and is therefore always only the "upper left corner" of the full hd internal representation...?).
I don't understand this one. Are we still talking about TFT displays (which are SPI) or HDMI panels ? They are separate outputs, and QLC+ cannot render on both simultaneously.
To change the HDMI resolution, search with Google how to tweak the config.txt file on Raspberry Pi images: https://www.raspberrypi.org/documentati ... fig-txt.md
User avatar
alegrechi
Posts: 6
Joined: Sun Apr 12, 2015 5:08 pm
Location: Florence - Italy
Real Name: Alessandro Grechi
Contact:

Amazing goal, Massimo! :)
I would like to try it ASAP.... :mrgreen:

Is it a resistive or capacitive touchscreen?
User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

alegrechi wrote:Amazing goal, Massimo! :)
I would like to try it ASAP.... :mrgreen:
Is it a resistive or capacitive touchscreen?
Thanks Alessandro. It took a while but in the end I made it :)

Normally those cheap touchscreens are resistive and I'm not even sure if they are multitouch.

By the way I realized that in the picture I took I had overscan enabled. If I disable it, I should gain a few more pixels and the screen should be fully covered ;)
User avatar
Frank
Posts: 66
Joined: Tue Jun 09, 2015 7:34 am
Real Name: Frank

Hi Massimo,

please excuse my silly questions I asked before, but the (internal) software implementation isn't easily to understand, with the exception of you of course...

I love the possibilities to use the Raspi together with QLC+, but I'm not competent to make changes inside your software development, inside Qt 5 and so on.

And now, as you implemented the use of a small LCD, the potential of these project grew up many times, in my opinion...

But I think that I'm not the only one who needs some advice to get it working perfectly. All the hints necessarily for using a touchscreen, should be prepared in a way that is very clearly to understand, not only for experts like you...

Sometimes the success of such a project depends on the comprehensibleness of the instructions given by the developer and/or the users, that implemented it succesfully... So I would like to help this way by asking for some details, that are visible not until the whole equipment is running reasonably.

Your picture was showing a black border (left, right and top side of the visible area). Afterwards you mentioned: "By the way I realized that in the picture I took I had overscan enabled. If I disable it, I should gain a few more pixels and the screen should be fully covered".

My question: Where should one disable overscan do get a full size screen?
For me my screen looks similarly to your one, and (maybe) therefore the touch position doesn't meet the content (buttons and so on) correctly, even if the discrepancy isn't too much. But it could be some better... Therefore I'm looking for a possibility to calibrate the touch accuracy. Perhaps you found a "data file" that is responsible for that...?

Thank you in advance
Frank
d3_fwFJ7fPKEL5SBgn3KQhWTwiCKAPatMxMF8VEZVSM[1].jpg
Last edited by Frank on Sun Jun 21, 2015 4:29 pm, edited 4 times in total.
User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Frank wrote:Hi Massimo,
...
But I think that I'm not the only one who needs some advice to get it working perfectly. All the hints necessarily for using a touchscreen, should be prepared in a way that is very clearly to understand, not only for experts like you...
Sometimes the success of such a project depends on the comprehensibleness of the instructions given by the developer and/or the users, that implemented it succesfully... So I would like to help this way by asking for some details, that are visible not until the whole equipment is running reasonably.
Your picture was showing a black border (left, right and top side of the visible area). Afterwards you mentioned: "By the way I realized that in the picture I took I had overscan enabled. If I disable it, I should gain a few more pixels and the screen should be fully covered".
My question: Where should one disable overscan do get a full size screen?
PS: I tried to append a photo via Dropbox link but it isn't displayd here... :oops: What should I do...?
You see Frank, one becomes an "expert" if he spends time on reading and learning with what is available on the internet.
To make the display working on the RPi, I haven't invented anything, and I haven't modified QLC+ or Qt. I've just spent some time reading forums, documentation and valuable information of people that succeeded before me.
It's all public and available to everyone, even you.

I suspect you find it easier to ask to me instead of spending the time I mentioned above. For example, how to set/unset the overscan is written in chapter 6 of the QLC+ RPi user guide PDF. Have you read it at all ?
Another example is "how do I attach a Dropbox picture in a phpBB forum". You save it into your computer and then attach it back here. This doesn't require to be an expert to get answered. Otherwise Google can help you.

As for "Sometimes the success of such a project depends on the comprehensibleness of the instructions given by the developer and/or the users, that implemented it succesfully", is exactly what I did with my post above.
I shared the information that I consider "relevant" to make the display to work with QLC+. Relevant to people that have a basic knowledge of a Linux system.
I cannot spend my time to give lessons on how to use Linux and it is not the purpose of this forum anyway. When someone buy a Raspberry Pi, he should be aware that it runs Linux and not Windows, OSX or Android.
The Raspberry Pi itself is a successful project and has a huge community sharing information on their forums. QLC+ is just an application, and here we discuss things around it, not generic ones.

This is the reason why I preferred to provide a software image made by myself, instead of providing the information to make QLC+ running on the RPi (which are public anyway), thing that would have caused a million of questions which I don't have the time or the patience to answer.

Honestly, I would expect the other way around: users succeeding in using particular devices with the RPi should share how they did it in this forum.
Sadly this never happens, and to me it explains a lot of things about this community that 99% of the times asks and 1% gives.
User avatar
Frank
Posts: 66
Joined: Tue Jun 09, 2015 7:34 am
Real Name: Frank

Hi Massimo,

I'm aware of the big effort you're giving to us when developing (or further developing) QLC+ for Rpi, really!!!

If one knows the functional range of QLC+ (or at least part of it) by using it at a conventional PC for example, then the next wish is to make it running on a "mobile" device. These days this could be a "micro" PC, a ..., or a Rpi (thanks to your development activities!).

I don't think that every interested person should firstly increase his knowledge to a level, that is high enough to understand all the implemented parts of software to make it running... If this should be the necessary requirements, only a very few amount of potential interested persons would come into consideration of using this platform. People that are interested in using QLC+ won't be very often software experts, I think. They are "experts" of lighting shows, musicians and so on... Of course, some understanding of Linux is necessary if one wants to use a Rpi for these purposes (similarly to the knowledge required when using QLC+ on Windows for example).

So please be clemently with "us" because only questions can clarify the problems...

For example, if you already know that a calibration of the touchpanel isn't possible at all (because of the implementation inside Qt 5) so please express it clearly to avoid any misunderstanding. Contrary - if it should be possible, but you don't have enough time to do it by yourself - please deliver a link to the place where the knowledge could be found, for "beginners" like me...

I would like to share any experience of using a TFT with everyone, but if everybody looks for the same issues by himself, the progress won't come, sorry.

Reducing the applicability of the Rpi together with only one tested touchscreen (480 x 320) is not the problem, as long as this type of TFT is deliverable at all.
To understand what should be done for connecting another type of TFT (if supported by the underlying FBTFT driver, included in the actual Rpi kernels), would be very desirably.
To have the possibility to calibrate the touchfunction by the user (because of inaccuracy of the touch surface during manufacturing the TFT) is very important in my opinion.

Please - again - help with your expert knowledge to clarify if there should be a solution.

Many, many thanks in advance
Frank
Nicko453
Posts: 17
Joined: Wed Jun 17, 2015 4:42 am
Real Name: Nick Rowland

Hi Massimo,

I'm trying to get a touch screen working on my RPi 2. Its a chinese generic 5" XPT2046. Works OK with the vendor's drivers, but their installation process updates a lot of kernel files etc.

I'm now trying to get the screen working with a fresh copy your QLC+ image, using your instructions above, to maximise supportability into the future.

Now for the dumb question !

In your original post, regarding editing the /etc/init.d/qlcplus file, when you say ..
-platform linuxfb:fb=/dev/fb1 -plugin evdevtouch:invertx
... should this be included within the quotes, as parameters to QLC+ ? ie
QLCPLUS_OPTS="-platform linuxfb:fb=/dev/fb1 -plugin evdevtouch:invertx --web --operate"

Many thanks,
Nick
Last edited by Nicko453 on Tue Jun 30, 2015 1:44 pm, edited 1 time in total.
Post Reply