Allow TOUCH_BUTTONS to be swapped

[robbycandra]

For Prusa Model Printer, then
The Toolhead will move UP when EN_B ("+" Button Pressed)

For Hypercube Printer, then
Bed will move DOWN when EN_B ("+" Button Pressed).

Therefore the UP and DOWN sign at touch button can make user confused.
The Solution is to enable REVERSE MENU DIRECTION and change the Button Icon accordingly.

---

We also need to seperate Encoder Handling that processed at update_buttons(). Therefore the process should be done before processing input from touch screen.

[thinkyhead]

I prefer narratives over proses.

[thinkyhead]

This value should be different when navigating a menu versus when editing a value. But perhaps on the touch display the "pulses per step" is always set to 1…?

[thinkyhead]

Hmm… By default the ENCODER_PULSES_PER_STEP falls back to 5. If the TOUCH_BUTTONS are the only encoder, then this can be set to 1 to slightly simplify the code. Is it possible for TOUCH_BUTTONS to exist alongside a regular click-wheel encoder?

[robbycandra]

@thinkyhead , I propose this code. The reason is to prepare full area touchscreen

[thinkyhead]

A full touch-screen is going to need an entirely different approach and won't go through this "button" nonsense. Sorry about trouncing BTN_D. An oversight.

[thinkyhead]

At present the vertical touch coordinate alone isn't going to very useful since we have a variety of screen layouts in Marlin. Every single screen layout type will need to have its own method to interpret touches and pass them on to the correct handlers. In cases where we only have a touch screen and no other buttons, we don't need to have up/down buttons on the screen unless something will actually be moved up/down. For menus, it will be better to have square buttons instead of textual menu items where possible, and textual menu items will need to be spaced apart more so that touches are less likely to invoke the wrong item. It will be better to write a new handler for these events rather than keep hacking everything on top of the rotary encoder.

[tpruvot]

sorry, i had the "slider" picture in my head, the component name

[robbycandra]

https://youtu.be/ClhTLofXOnA Check this out.

[tpruvot]

very good yep, but as i said before, this is not the upscale dogm anymore...

[thinkyhead]

I like the bare-bones text in a simple line-box for the menu items. Color-coding by type is also cool, where yellow might mean "editable," and so on. If there were more buttons than could fit on the screen, it would get a pager, I suppose. But the nice thing about such a bare-bones approach is that it may encourage people to want to make it more interesting. But can it do all the languages?

[github051]

https://youtu.be/ClhTLofXOnA Check this out.

Hi Can you provide the config files for MKS robin TFT

[thinkyhead]

I've simplified the code so it passes the EN_C bit on to the buttons variable for standard handling while adding a separate flag to indicate an arrow is being held down and that it should be repeated if it stays held down. The new flag costs a byte SRAM, but I threw away the touch_buttons global to recover the byte.

[robbycandra]

I think return Value from touch.read_button should be coordinate only, to make the code universal for all type of display mode.

then we make a function in MarlinUI that determine what button is touched in that position.
The function will be writen in ultralcd_something.cpp.

[tpruvot]

try to git diff tpruvot/master Marlin/src/feature/touch/

I had to add this function for the calibration "app", basically :

+bool XPT2046::getTouchPoint(uint16_t &x, uint16_t &y)
+{
+  if (!isTouched()) return false;
+  x = getInTouch(XPT2046_X);
+  y = getInTouch(XPT2046_Y);
+  if (!isTouched()) return false;
+
+  return true;
+}

[tpruvot]

Else, just tested the PR as one commit, and the behavior is fully reversed..

Menus are reversed and buttons - + do the opposite as what they should do... for values

To be short: cant be worst misconfigured, reversed arrows position and also -/+

[robbycandra]

Its working on my MKS Robin mini. But the code is a mesh now.

@tpruvot , can you message me on discord ?

[tpruvot]

if i (only) set REVERSE_ENCODER_DIRECTION, arrows are ok, but values editing are reversed.

Also, im not sure its related, but the ok/menu button often go down now... i need more tests without the commit and/or double check the default X calibration..

[tpruvot]

Fix required to set "minus" negative by default, fix both cases.. but remains the OK problem, only the OK seems to have EN_B position conflict on the touchscreen

diff --git a/Marlin/src/lcd/ultralcd.cpp b/Marlin/src/lcd/ultralcd.cpp
index 98f15fb07..85541af07 100644
--- a/Marlin/src/lcd/ultralcd.cpp
+++ b/Marlin/src/lcd/ultralcd.cpp
@@ -791,7 +791,7 @@ void MarlinUI::update() {
           buttons |= (touch_buttons & (EN_C | EN_D));   // Pass on Click and Back buttons
           if (touch_buttons & (EN_A | EN_B)) {          // A and/or B button?
             encoderDiff = (ENCODER_STEPS_PER_MENU_ITEM) * (ENCODER_PULSES_PER_STEP) * encoderDirection;
-            if (touch_buttons & EN_B) encoderDiff *= -1;
+            if (touch_buttons & EN_A) encoderDiff *= -1;
             next_button_update_ms = ms + 50;            // Assume the repeat delay

[robbycandra]

@tpruvot, change

-            if (touch_buttons & EN_B) encoderDiff *= -1;
+            if (touch_buttons & EN_A) encoderDiff *= -1;

Have same effect with REVERSE_ENCODER_DIRECTION, cause it just switch between EN_A and EN_B

our LCD touch work with REVERSE_ENCODER_DIRECTION enabled (=marlin default)
REVERSE_MENU_DIRECTION can be enabled or disabled depend on our need.

I test, the code is ok now. Except you need to switch from
' X , - , + , Ent ' ----> ' X , + , - , Ent '

[tpruvot]

i dont want a + on the left, its fully illogic