New build black screen

Once everything is fully working and tested, I’ll do the write up with full details.



1 Like

Hi, hopefully a quick and simple question, but what is the correct way to manage screen axes calibration? I tried multi configurations in /etc/X11/xorg.conf.d/99-calibration.conf

So far I tried using the keyboard to navigate to the menu on the UI, along with the xinput_calibrator writing out to 99-calibration.conf and various combinations passed to the dtoverlay in UI config (e.g. invx=), but nothing seems to be making any difference.

The screen is the right way up, but stylus up is left, down is right etc.


IT runs in a similar fashion (touchscreen reversed) on a Pi 3 but a mouse exhibits the select the first element in the list effect alluded to elsewhere… Using it from a arduino encoder box occasionally goes down the select list but jumps back to the top selected item, same happens with a keyboard.

So it looks like I can resurrect zynthian-touch.local.

It runs testing too…

Hey @wyleu, thanks for the reply.

Sorry if I’m misunderstanding, are you saying the axes can’t be rotated and a mouse is needed in this instance?


The behaiour seems very similar to what is reported here …

Ahhhh…interesting, I didn’t see that post from @le51

From the testing I’ve done so far, I’m able to run the input_calibrator without issue and it seems to spit out the relevant mappings, it just seems the O/S isn’t using/detecting the config.

I’m keen not to use keyboard and mouse if possible, the new setup I’ve just constructed was largely intended to not feel computer driven (see pic). That said, I’ve currently got the Zynthian box doubling up as a Midi interface which is handy =)

Worst case I will just get a supported and tested screen I think, but will try to do more on the config of this one and will post any progress.

Yes, this has all the feel of the original dance we had to do to get this to function. I learnt one hell of a lot about screen details which I promptly forgot.

In theory you should be able to access the admin/screen calibration using a USB keyboard or mouse and then calibrate using touch. After this, touch should work as expected. I think someone once reported this didn’t work for them but I’m not sure I saw a GitHub issue report.

1/ git clone GitHub - goodtft/LCD-show: 2.4" 2.8"3.2" 3.5" 5.0" 7.0" TFT LCD driver for the Raspberry PI 3B+/A/A+/B/B+/PI2/ PI3/ZERO/ZERO W
2/ cd LCD-show/
3/ cp ./usr/tft35a-overlay.dtb /boot/overlays/
4/ cp ./usr/tft35a-overlay.dtb /boot/overlays/tft35a.dtbo

5/ * via webconf:
Hardware → kit → custom → save
Display → custom-> set :

width:—> 480
height:—> 320
framebuffer:—> /dev/fb1

6/ Restart
7/ Screen displays correctly.
8/ Touch screen XY reversed i.e. vertical movelments produce horizontal movement of cursor
9/ Attempting to select items on screen in admin virtually impossible with reversed axis, and mouse operation continually drops back to selecting top menu item, similar behaviour with keyboard ( re-position not triggered by anything specific it just moves back)
10/ Any attempt to select a different menu item selects the top item in select list…
11/ Hurl device at wall using technique described by @riban and chuckle lightly at being the person who gave him the screen.

LOL @wyleu - replace step 11 with ‘Slow deep inhale through the nose and breath slowly out the mouth’ * 5.

As promised I’m drafting my installation notes and will make them pretty and ready to share once everything is working. The notes will include:

  • Direct links to hardware used and link to driver/overlay repo.

  • Note on issues encountered with Etcher and a work around for Mac or Linux users to write the SD image using diskutil and dd. (will include warning)

  • Process used to access the device initially without using a keyboard and monitor (using ethernet and then nmap or your router to determine IP address and then Wifi setup via the Webconf)

  • Process to copy overlay files to /boot/overlays

  • Initial Webconf hardware setup including Custom Kit, Audio, Display and Wiring etc.)

  • Method used to setup a Midi Interface (Midisport 2x2)

  • Method used to have the system recognise KeystationMini 32 direct over USB

  • Method used to check Midi signal is working.

  • A method to work around the screen axes inversion issue (use of a small wireless Logitech K400 with touch pad)

  • Links to Project documentation and getting started video.

However, … although we now have the web ui working, midi working , screen working, …the sound is not working, the best I can get after creating a layer is a barely audible sound with what sounds like interference over it.

I can see the midi register and the green bars indicating volume, but the sound is not working. I’m assuming there may be some further configuration required for the Raspberry Pi 4B (Model B) Rev 1.2?

I will trawl the forum for sound issues, but if there are any basic setup steps I’ve missed for the 4B, please let me know.

Edit:Details of sound card below - I will work through standard raspberry pi sound troubleshooting issues and confirm if sound is working outside of Zynthian.

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3

card 2: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 3/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3

EDIT UPDATE: I can confirm in webconf I’m using the default ‘Rbpi Headphone’ option.


I don’t think rotate has an effect on this driver. My screen is upside down and the parameter does not change it. I can’t test further because I only have a spare RPi2 which won’t run the Zynthian version of jackd.

What sound device have you selected in webconf. You don’t have any soundcard connected so must select Headphones.

Sorry, I should have mentioned I have headphones selected in the webconf.

I’m just reading over the troubleshooting methods on raspberry pi forum, seems others had the similar issue with RP4.

When I’m not using a sound card, I have to select Hifiberry DAC+light and then go to admin menu and check RBPi Headphones to make it work.

Thanks @ronsum , just tried , didn’t work for me.

I’ll keep looking tomorrow.


What Raspberry Pi are you using. I don’t see that mentioned in this list.

Headphone output is notoriously poor. Recent driver improvements has made it tolerable but it uses a lot of processing which steals from the important DSP, i.e. use of headphone output will trigger earlier onset of xruns (audio discontinuity manifesting as clicks). Also, if you have another sound interface enabled and enable Headphones you have this issue plus the added samplerate conversion required to sync different audio clocks.

Give us a sample of the sound - it may help diagnose the issue.

I’m on a Pi3 using a Yeti as Audio interface.

But you aren’t having the audio issues that @Buddhafiner is having. (I should have targeted my question.)

I see that this driver ignores the “rotate” parameter and always sets rotate to 90. I wonder if that is why the screen calibration is failing. I am debugging that now. Screen calibration should work. It seems to be doing the right things, i.e.

  • Reset calibration
  • Get new settings based on the reset state
  • Apply new settings
  • Save new settings

but the new settings result in 90 degree clockwise rotation of touch. (BTW if you know that you can drive the screen more easily.) Investigation continues…

I am not seeing the issue described by @wyleu regarding driving the interface. I can easily use VNC to access the interface then use mouse or keyboard to select Admin/Touchscreen Calibration then do the calibration on the real screen (which of course fails due to the issue described above). I don’t see any jumping to the top of the screen as I manipulate with mouse / keyboard. Do you (@wyleu) have some damage / pressure to the screen triggering unexpected touch activity?

I’m possibly queering the test as I’m running testing. Are we all comparing like with like?