LCDproc port

cjohnson

What would be a good way for me to workaround the webUI limitation of port address selections? Currently, the highest port address that I can pick in the webUI is /dev/ugen2.2. My Matrix Orbital USB display appears at /dev/ugen3.2. Do I do something like disable lcdproc in the webUI then make my own LCDd.conf file and run it with shellcmd or something? I've considered editing the php include for the webUI, that might get me by for now... 'till i have to upgrade to the next pfsense release and that all gets blown away. :-/

On the other hand I've seen other posts that seem to indicate that I should be using /dev/cua0 instead. I have tried those other options, however "ps -aux | grep -i lcd" doesn't seem to show me that LCDd or any of the related services/daemons are staying running so I feel like maybe the port is wrong and it's causing LCDd to fall over and die. If it's of any use, I'm working with a "LK202-25 ". All of this is being done on a freshly installed 2.5.2 box and the latest available stable lcdproc package.

Thanks to anyone that can help in advance....

bingo600

@cjohnson

My "Crystal Ball" is unfortunately a bit foggy today.
It won't reveal what kind of LCD interface type you are using to connect to the Unknown pfSense box type & model

As per this
https://www.matrixorbital.com/lk202-25
The diaplay have multiple interfaces:

20x2 LCD 1U HMI with Serial RS232, TTL,USB, I2C

I guess you have to wait for my Crystall Ball" to clear up , or supply the missing info.

/Bingo

cjohnson

@bingo600

Maybe you can put the crystal ball away and re-read my first post.

"My Matrix Orbital USB display appears at /dev/ugen3.2."

cjohnson

i'm trying this now on another different x86 box. this is now on an x86 EPC4 machine running pfsense 2.5.2.

some info and troubleshooting data here....
netgateforum.txt

what i'm using for a config is now this....

cat /usr/local/etc/LCDd.conf
[server]
DriverPath=/usr/local/lib/lcdproc/
Driver=MtxOrb
Bind=127.0.0.1
Port=13666
ReportLevel=3
ReportToSyslog=yes
User=nobody
Foreground=no
ServerScreen=no
GoodBye="Thanks for using"
GoodBye="    pfSense     "
WaitTime=5
ToggleRotateKey=Enter
PrevScreenKey=Left
NextScreenKey=Right
ScrollUpKey=Up
ScrollDownKey=Down
[menu]
MenuKey=Escape
EnterKey=Enter
UpKey=Up
DownKey=Down
[MtxOrb]
Device=/dev/ugen1.2
Size=20x2
Type=lkd
hasAdjustableBacklight=yes
Reboot=no
Contrast=480
Brightness=1000
OffBrightness=0

none of the lcd processes/daemons seem to be starting/running from what i can tell by using "ps -aux | grep -i LCD". there are no errors in /var/log/system.log. this output in that log is just after a disable > save > enable > save within the webUI.

Feb 17 16:17:45 router1 check_reload_status[374]: Syncing firewall
Feb 17 16:17:45 router1 php-fpm[337]: lcdproc: Sync: Begin package sync
Feb 17 16:17:45 router1 php-fpm[337]: lcdproc: Sync: End package sync

cjohnson

@bingo600

In addition to all that stuff above... all of the behaviors/output appears similar even after an upgrade to pfsense 2.6.0. There just doesn't seem to be a /dev/cuaUx device created. It seems that's what other people with matrix orbital usb attached displays are/have been using to point lcdproc at.

cjohnson

The end result (that wouldn't involve recompiling my own kernel/drivers etc) was to simply change the VID/PID in the display from the out of box settings of 0x1b3d/0x0155 to the FTDI defaults of 0x0403/0x6001. You can do this with "FT_Prog" on another computer running Windows or you can do it with another computer using "ft232r_prog" on Ubuntu Linux.....

sudo ./ft232r_prog --old-vid 0x1b3d --old-pid 0x0155 --new-vid 0x0403 --new-pid 0x6001

ft232r_prog: version 1.25, by Mark Lord.
       eeprom_size = 128
         vendor_id = 0x1b3d
        product_id = 0x0155
      self_powered = 0
     remote_wakeup = 0
suspend_pull_downs = 0
     max_bus_power = 500 mA
      manufacturer = MO
           product = LK202-25-USB
         serialnum = 01wwkXXX
   high_current_io = 0
  load_d2xx_driver = 0
      txd_inverted = 0
      rxd_inverted = 0
      rts_inverted = 0
      cts_inverted = 0
      dtr_inverted = 0
      dsr_inverted = 0
      dcd_inverted = 0
       ri_inverted = 0
           cbus[0] = TxDEN
           cbus[1] = TxDEN
           cbus[2] = TxDEN
           cbus[3] = PwrEn
           cbus[4] = TxDEN
Rewriting eeprom with new contents.
/tmp/MO/ft232r_prog-1.25$ sudo ./ft232r_prog --save MO-lk202-25.dump

ft232r_prog: version 1.25, by Mark Lord.
MO-lk202-25.dump: wrote 128 bytes
       eeprom_size = 128
         vendor_id = 0x0403  <---- IT'S DIFFERENT NOW
        product_id = 0x6001  <---- AND THIS IS TOO
      self_powered = 0
     remote_wakeup = 0
suspend_pull_downs = 0
     max_bus_power = 500 mA
      manufacturer = MO
           product = LK202-25-USB
         serialnum = 01wwkXXX
   high_current_io = 0
  load_d2xx_driver = 0
      txd_inverted = 0
      rxd_inverted = 0
      rts_inverted = 0
      cts_inverted = 0
      dtr_inverted = 0
      dsr_inverted = 0
      dcd_inverted = 0
       ri_inverted = 0
           cbus[0] = TxDEN
           cbus[1] = TxDEN
           cbus[2] = TxDEN
           cbus[3] = PwrEn
           cbus[4] = TxDEN
No change from existing eeprom contents.

Once that's done, you can plug it back in to pfsense and the driver will pick it up and ugen will do it's thing etc.... You'll finally end up with all of the

/dev/cuaU0
/dev/cuaU0.init
/dev/cuaU0.lock

things that you need in /dev/ that you can then use to point the webUI/lcdproc towards.