Python driven smart screens

[majormer]

I'm working on a few different dashboards driven by Python scripts. I have created and shared some performance dashboards, and even an Outlook calendar dashboard (recently lost access to my work Outlook on my personal device, so I'm no longer updating that).

Over the last week, I have been developing some dashboards that can be configured with YAML files for preferences. I'm also created some standard python functions that can leverage YAML files for the configuration of the Turing screen. For example, this is possible!

# Configuration for 5-inch Turing Smart Screen Stats Dashboard

# Device configuration
device:
  type: "5inch"            # Device type: '5inch', '3_5inch', '7inch'
  library: "LcdCommRevC"   # LCD library class to use
  com_port: "AUTO"        # COM port or 'AUTO' for auto-detection
  width: 480              # Screen width in pixels (physical width in landscape: 800)
  height: 800             # Screen height in pixels (physical height in landscape: 480)
  orientation: "landscape"  # 'landscape' or 'portrait'
  brightness: 50          # Screen brightness (0-100)
  full_refresh_every: 30  # Frames between full refreshes (0 to disable)
  font_path: "UPSTREAM_FONT"  # Special value to use the upstream JetBrains Mono font

Using python is super powerful for these USB screens, and I am grateful to @mathoudebine for his work in enabling the APIs to use them!

Consider this:

This is a dashboard I created that will check latency and response status of systems I care about in my home lab. I have three pages of applications/hosts that it needs to track, so it will rotate to the next page every 15 seconds. The number of pages is programmatically determined based on all the hosts I have in my YAML config. I also have the key things to look at when you are having connectivity issues, like... is my DNS working? How about my router? My fiber gateway? How about Google? By looking at that chain, I can quickly determine why my World of Warcraft is lagging or disconnecting! I also have a focus app that can be defined in YAML that will make sure that a single app or host that I need to track is visible all the time. That could be your remote Minecraft server, or even OpenAI's website when they are overloaded and you realize you don't really know anything without AI anymore!

I'm trying to find good ways to contribute these back to the community to build off the framework. I have my own git server I have my scripts versioned to, but the result is that it is targeting this repo for its libraries. I might need to create a YAML file where I can just enter the location of the cloned repo so all scripts know to use that as a relative path for all the libraries.

---

One other thing I was able to do thanks to leveraging Python over the themes and the original Turing software is that I can go multithreaded for my information. That means, I could have CPU data loading in one thread, GPU data in another (GPU calls are really slow!), then just refresh super quick, and just check for updates from the threads. The upshot of that is 3 to 6 fps refreshes for large dashboards instead of 2 or 3 second refreshes.

---

As I said, I'm working on a framework that I hope to be able to share soon. This has been a game-changer, however, on how I am using my little USB screens!

I'll update this thread when I have more to share!

Cheers!

[majormer]

Here is an example of how my performance dashboard "script" is now working...

System Stats Dashboard for Turing Smart Screen

A modular, highly-configurable dashboard for displaying real-time system statistics on Turing Smart Screen devices.

Table of Contents

1. Features
2. Statistics Displayed
3. Directory Structure
4. Architecture
5. Configuration System
6. Module Structure
7. Core Functionality
8. Enhancement Possibilities
9. Troubleshooting

Features

• Real-time hardware monitoring through LibreHardwareMonitor
• Thread-safe background stats collection
• Configurable through YAML
• Modular, extensible architecture
• Adaptive layout system
• Automatic hardware detection
• Watchdog for stability
• Graceful error handling

Statistics Displayed

• CPU: Total load, temperature, frequency, and per-core loads
• RAM: Usage information in MB and percentage
• GPU: Model, utilization, temperature, clock speed, and memory usage (both NVIDIA and AMD supported)
• System: Uptime and current date/time

Directory Structure

system_stats_dashboard/
├── __init__.py           # Package initializer
├── config.py            # Configuration management
├── dashboard.py         # Main dashboard controller
├── hardware.py          # Hardware monitoring and stats collection
├── lcd.py               # LCD screen initialization and management
├── main.py              # Entry point for the dashboard
├── utils.py             # Utility functions
├── sections/            # Dashboard sections
│   ├── __init__.py      # Sections package initializer
│   ├── base.py          # Base Section class
│   ├── cpu.py           # CPU header and stats sections
│   ├── gpu.py           # GPU stats section
│   ├── ram.py           # RAM stats section
│   └── system.py        # System information section
└── README.md            # This documentation file

Architecture

The dashboard follows a component-based architecture with clear separation of concerns:

Key Components:

1. Dashboard Controller: Centralizes layout management, rendering coordination, and lifecycle control
2. ConfigManager: Handles configuration loading, validation, and provides sensible defaults
3. StatsManager: Manages hardware monitoring and provides thread-safe data access
4. Section Classes: Independent display components for different hardware metrics
5. Layout Manager: Calculates optimal positioning for all elements to prevent overlap

Data Flow:

1. Hardware Data Collection: Background threads collect hardware stats at configured intervals
2. Thread-safe Caching: Data is stored in thread-safe structures for access by the rendering system
3. Layout Calculation: Element positions are calculated based on screen dimensions and content
4. Section Rendering: Each section pulls data from the StatsManager and renders to the display
5. Display Updates: The LCD driver handles the actual display operations

Configuration System

The dashboard uses a YAML-based configuration system with fallback defaults. The ConfigManager class handles loading, validation, and access to configuration settings.

Configuration File Structure

preferences:
  refreshInterval: 0.1             # Screen refresh rate in seconds
  brightness: 50                   # Display brightness (0-100)
  orientation: 'landscape'         # Screen orientation
  fullRefreshInterval: 5000        # Full screen refresh interval to prevent ghosting

update_intervals:
  cpu: 0.2                         # CPU stats update interval in seconds
  ram: 0.2                         # RAM stats update interval in seconds
  gpu: 2.0                         # GPU stats update interval in seconds

# Hardware monitoring configuration
hardware:
  cpu:
    enabled: true                  # Enable CPU monitoring
    show_cores: true               # Show individual core loads
    max_cores_displayed: 16        # Max number of cores to display

  gpu:
    enabled: true                  # Enable GPU monitoring
    auto_detect: true              # Automatically detect GPU devices

# Display and rendering configuration
layout:
  font:
    path: UPSTREAM_FONT            # Font path (special value for JetBrains Mono)
    size_normal: 18                # Normal text size
    size_small: 16                 # Small text size
    size_large: 24                 # Large text size for headers
    char_width: 9                  # Approximate character width for positioning

  # Comprehensive color customization system
  colors:
    # Background colors
    background: [0, 0, 0]           # Black background for all sections
    heading_background: [0, 0, 0]   # Background for section headers
    
    # CPU section colors
    cpu:
      header: [255, 255, 255]       # CPU STATS header (white)
      name: [255, 0, 0]             # CPU model name (red)
      label: [255, 0, 0]            # Labels for CPU stats (red)
      value: [255, 255, 255]        # Values for CPU stats (white)
      bar:
        fill: [255, 0, 0]           # CPU progress bar fill (red)
        outline: [255, 128, 128]    # CPU progress bar outline (light red)
    
    # GPU section colors
    gpu:
      header: [255, 255, 255]       # GPU STATS header (white)
      name: [0, 255, 0]             # GPU model name (green)
      label: [0, 255, 0]            # Labels for GPU stats (green)
      value: [255, 255, 255]        # Values for GPU stats (white)
      bar:
        fill: [0, 255, 0]           # GPU progress bar fill (green)
        outline: [128, 255, 128]    # GPU progress bar outline (light green)

    # Similar structure for RAM and system sections
    color: [0, 128, 0]             # RGB color for GPU elements
    auto_detect: true              # Automatically detect GPU models
    devices:                       # Manual GPU configuration if auto_detect is false
      - {filter: '4090', enabled: true}
      - {filter: '4080', enabled: true}

  ram:
    enabled: true                  # Enable RAM monitoring
    color: [255, 0, 0]             # RGB color for RAM elements

  system:
    show_uptime: true              # Show system uptime
    show_clock: true               # Show system clock
    color: [255, 255, 255]         # RGB color for system info elements

layout:
  background_image: 'background.png'   # Background image path
  bg_color: [0, 0, 0]                  # Background color (RGB)
  font:
    path: '/path/to/font.ttf'          # Font file path
    size_title: 22                     # Title font size
    size_normal: 20                    # Normal text font size
    size_small: 16                     # Small text font size
  
  # Progress bar styling
  progress_bar:
    height: 12                         # Bar height in pixels
    width: 320                         # Standard bar width in pixels
  
  # Section definitions
  sections:
    - {name: 'cpu_header', position: [10, 10], static: true}
    - {name: 'cpu_stats', position: [10, 70]}
    - {name: 'ram_stats', position: [10, 0]}  # Dynamic position
    - {name: 'gpu_stats', position: [420, 40]}
    - {name: 'system_info', position: [400, 440]}

Configuration Resolution Process

1. Default Configuration: Built-in default settings ensure the application works out-of-the-box
2. User Configuration: Settings from the YAML file override defaults
3. Deep Merging: User settings are recursively merged with defaults to maintain structure
4. Validation: Paths are validated and resolved to absolute paths
5. Fallbacks: If critical components like fonts are missing, fallbacks are provided

Module Structure

dashboard.py - Main Controller

The Dashboard controller acts as the central orchestrator with responsibilities:

1. Initialization: Sets up hardware monitoring, display, and section layout
2. Section Management: Creates, positions, and organizes dashboard sections
3. Rendering Pipeline: Manages static vs. dynamic rendering with optimizations
4. Layout Coordination: Prevents section overlaps using calculated positions
5. Event Handling: Manages user inputs and system events
6. Lifecycle Management: Handles startup, shutdown, and cleanup

hardware.py - Hardware Monitoring

The StatsManager provides thread-safe access to hardware metrics:

1. Background Monitoring: Runs hardware monitoring in separate threads
2. Thread Safety: Uses locks to prevent race conditions during data access
3. Cached Updates: Collects data at configurable intervals to minimize overhead
4. Hardware Detection: Automatically detects CPU and GPU information
5. Data Formatting: Prepares and normalizes data for display

sections/base.py - Section Framework

The Section base class provides common functionality for all display sections:

1. Positioning: Handles absolute and relative positioning
2. Background: Controls section background (transparent or colored)
3. Clearing: Provides methods to clear previous renders
4. Dimensions: Tracks rendered area for layout calculations
5. Configuration Access: Shared configuration access methods

Section-Specific Implementations

Each specialized section extends the base Section class:

1. cpu.py: Implements CPU header and stats sections with core visualization
2. gpu.py: Implements GPU visualization with support for multiple GPUs
3. ram.py: Implements RAM usage visualization
4. system.py: Implements system information like uptime and date/time

Core Functionality

Threading Model

The application uses a thoughtful multi-threading approach:

1. Main Thread: Handles rendering and display updates
2. Hardware Monitoring Threads: Separate threads for each hardware component
3. Watchdog Thread: Monitors for hanging or freezing
4. Thread Synchronization: Using locks and events for coordination

Layout System

The dashboard employs a sophisticated layout system to ensure consistent spacing and positioning of elements:

1. Column-Based Layout: Elements are arranged in left and right columns
2. Automatic Positioning: Sections position themselves based on available space
3. Consistent Spacing: Maintains uniform spacing between headers and content (40px)
4. Dynamic Adjustment: Sections can adjust position based on previous sections
5. Intelligent Centering: Uses consistent character width multipliers for text centering
6. Collision Avoidance: CPU sections dynamically adjust positioning to prevent overlaps
7. Color Separation: Uses consistent color schemes to visually differentiate sections

Layout Highlights

• Header Alignment: All section headers (CPU, GPU, RAM) use consistent spacing and alignment
• Content Separation: Clear visual separation between labels and values
• Progress Bars: Standardized bar sizes and positions across all sections
• Multi-core Display: Optimized layout for 16-core CPUs (like Ryzen 9 9950X3D)

Rendering Optimizations

Several techniques minimize screen flicker and optimize performance:

1. Static vs. Dynamic Content: Static content renders less frequently
2. Partial Updates: Only changed areas are updated
3. Double Buffering: Prepare off-screen before updating display
4. Background Caching: Background elements are cached to reduce rendering load

Enhancement Possibilities

The modular design allows for several enhancement opportunities:

Additional Sensor Support

1. Network Section: Add real-time network bandwidth monitoring

   from system_stats_dashboard.sections.base import Section
   
   class NetworkSection(Section):
       """Section for displaying network information"""
       def render(self, lcd, stats_manager):
           # Implementation for network visualization

Troubleshooting

• Blank Screen: Check COM port configuration and device connection
• No Hardware Data: Ensure LibreHardwareMonitor is accessible to the application
• Missing Elements: Check configuration file for enabled/disabled components
• Performance Issues: Adjust update intervals for better performance
• GPU Not Detected: Ensure compatible GPU drivers are installed
• Temperature/Frequency Reading as '--': Administrator privileges are required for accessing some CPU temperature and frequency sensors
• Color Configuration Issues: Verify the YAML color structure follows the documented format
• Layout Overlap: Ensure consistent spacing in configuration

High CPU Usage

If the application uses excessive CPU resources:

1. Update Intervals: Increase the update intervals in configuration
2. Rendering Optimization: Reduce the number of dynamic sections or rendering frequency
3. Hardware Access: Adjust hardware monitoring timeout settings

Usage

Running the Dashboard

# From the 5inch directory
python run_system_stats.py

# Or directly from the package directory
python -m system_stats_dashboard.main

Administrator Requirements

Some CPU sensors, particularly temperature and frequency sensors on newer AMD Ryzen processors (including the 9950X3D), require administrator privileges to access. If you see these values displayed as '--' or '0', try running the dashboard as administrator:

# On Windows, run Command Prompt as Administrator, then:
python run_system_stats.py

Configuration

The dashboard is configured through stats_config.yaml located in the 5inch directory. Key configuration sections include:

• preferences: General dashboard settings (refresh rate, brightness, etc.)
• update_intervals: How often to refresh different hardware stats
• hardware: Settings for each hardware type (CPU, GPU, RAM, system)
• layout: Visual layout settings (background, fonts, colors, section positions)

Color Customization System

The dashboard implements a comprehensive color customization system that allows configuring colors for every element type within each section:

layout:
  colors:
    # Background colors
    background: [0, 0, 0]           # Black background for all sections
    heading_background: [0, 0, 0]   # Background for section headers
    
    # CPU section colors
    cpu:
      header: [255, 255, 255]       # CPU STATS header (white)
      name: [255, 0, 0]             # CPU model name (red)
      label: [255, 0, 0]            # Labels for CPU stats (red)
      value: [255, 255, 255]        # Values for CPU stats (white)
      bar:
        fill: [255, 0, 0]           # CPU progress bar fill (red)
        outline: [255, 128, 128]    # CPU progress bar outline (light red)
    
    # Similar structure for GPU, RAM, and system sections

This system allows for:

• Consistent Theming: Apply a consistent color scheme across the dashboard
• Visual Hierarchy: Use color to highlight important information
• Customized Appearance: Adjust colors to match your setup or preferences
• Element-Level Control: Customize individual element types (headers, labels, values, progress bars)
• Section-Specific Colors: Each hardware section can have its own color scheme

Extension

The modular architecture makes it easy to extend the dashboard with new sections:

1. Create a new section class in the sections directory that inherits from Section
2. Implement the render() method to display your data
3. Add your section to the create_sections() method in dashboard.py

Dependencies

• Python 3.7+
• pythonnet (for LibreHardwareMonitor integration)
• PyYAML (for configuration)
• PIL/Pillow (for image processing)
• LibreHardwareMonitor (included in upstream/external)

Error Handling

The dashboard implements several layers of error handling to ensure stability:

• Hardware detection fallbacks
• Watchdog thread to detect and log potential hangs
• Graceful COM port recovery
• Exception catching at critical points
• Safe shutdown hooks

Background and Development

This dashboard was originally developed as a monolithic script (stats5_new.py) and has been refactored into a modular, maintainable package structure while preserving all functionality. The modular approach allows for easier maintenance, extension, and troubleshooting.

[majormer]

20250510_160303.mp4

Here is how threading changes the game for performance of the Smart screen!

[majormer]

And here is an example of the Network Host Ping Monitor dashboard on my 3.5inch screen switching pages, enabling DYNAMIC content! And combined with stuff like API calls to external services, you could literally do anything! If my kid sets the thermostat to 90 degrees while it is 72 degrees outside and the windows are open, perhaps I grab that data from HomeAssistant and alert that BAD THINGS ARE HAPPENING! Garage door open for 1 hour after 8pm? That is probably something I should be aware of. Alert me!

20250510_160512.mp4

[majormer]

I mean come-on. When I configure output level to NONE, even the console is sexy!

# Logging configuration
logging:
  # Console output (stdout) settings
  console_level: NONE  # Disable console output entirely (NONE, DEBUG, INFO, WARNING, ERROR, CRITICAL)
  detailed_console_output: false  # When true, includes timestamps and more details in console output
  
  # File logging settings
  file_logging_enabled: false  # Disable file logging
  file_level: ERROR  # Log only errors and critical issues (DEBUG, INFO, WARNING, ERROR, CRITICAL)
  create_new_log_each_run: true  # When true, creates a timestamped log file for each run
                                 # When false, appends to stats_dashboard.log

[majormer]

Making quite a bit of progress to getting this closer to release. Currently, the plan is to create a new GitHub repo for managing Python based Turing screen management leveraging @mathoudebine 's work. I have a config YAML file that you would update with the path to the a cloned version of this repository.

I also have created a virtual device leveraging some of @mathoudebine 's virtual screen idea so that you can either run the dashboards on your smart screens or develop/run dashboards against virtual screens. At some point, you will just be able to pick the screen you have, and the dashboard you want to run, and it just works.

I have an abstraction layer between the device, the fonts/backgrounds, some canned common utilities to do things like refresh screens, use fixed-length labels, and centering/columns, etc. It is getting fun, folks!

Anyway, I'll keep posted and let you know when I release to GitHub. Just be aware that none of it works without this repo!