Skip to main content

Welcome Contributors!

Thank you for your interest in contributing to the Virtual Display Driver project! This is an open-source project that welcomes contributions from the community.
The Virtual Display Driver is developed by MikeTheTech (Project Manager, Lead Programmer) and Jocke (Programmer, Concept Design).

Ways to Contribute

There are many ways to contribute to the project:

Code Contributions

  • Bug fixes: Fix issues reported in GitHub Issues
  • New features: Implement requested features
  • Performance improvements: Optimize driver performance
  • Code quality: Refactoring and cleanup
  • Platform support: Improve ARM64 or other platform support

Documentation

  • Fix typos and errors: Improve documentation accuracy
  • Add examples: Provide usage examples and tutorials
  • Translate: Help translate documentation
  • Write guides: Create setup guides for specific use cases

Testing and Reporting

  • Bug reports: Report issues with detailed information
  • Feature requests: Suggest new capabilities
  • Testing: Test on different hardware configurations
  • Compatibility: Verify driver works with various applications

Community Support

  • Help users: Answer questions in discussions
  • Community scripts: Share PowerShell scripts and utilities
  • Tutorials: Create video guides or blog posts

Getting Started

1. Fork the Repository

  1. Visit Virtual Display Driver on GitHub
  2. Click the Fork button (top right)
  3. Clone your fork:
    git clone https://github.com/YOUR-USERNAME/Virtual-Display-Driver.git
    cd Virtual-Display-Driver
    

2. Set Up Development Environment

Follow the Build Requirements guide to set up your environment:
  • Install Visual Studio 2019/2022
  • Install Windows Driver Kit (WDK)
  • Configure build tools

3. Create a Branch

Create a feature branch for your changes:
git checkout -b feature/your-feature-name
Branch naming conventions:
  • feature/feature-name - New features
  • fix/bug-description - Bug fixes
  • docs/documentation-update - Documentation changes
  • refactor/component-name - Code refactoring

Making Changes

Code Style Guidelines

The project uses C++17 and follows Windows driver development best practices: General Guidelines:
  • Use clear, descriptive variable names
  • Comment complex logic and driver-specific behavior
  • Follow existing code formatting and style
  • Keep functions focused and reasonably sized
Driver-Specific Guidelines:
  • Use proper UMDF patterns and conventions
  • Handle all error cases with appropriate status codes
  • Use WPP tracing for diagnostics
  • Follow IddCx API usage guidelines
  • Validate all input parameters
Example Code Style:
// Good: Clear naming and error handling
NTSTATUS InitializeMonitor(IDDCX_MONITOR& monitor, unsigned int index) {
    if (index >= MAX_MONITORS) {
        return STATUS_INVALID_PARAMETER;
    }
    
    // Initialize monitor configuration
    NTSTATUS status = ConfigureMonitorModes(monitor, index);
    if (!NT_SUCCESS(status)) {
        TraceError("Failed to configure monitor modes: 0x%x", status);
        return status;
    }
    
    return STATUS_SUCCESS;
}

Testing Your Changes

Always test driver changes in a safe environment. Driver bugs can cause system instability or crashes.
Before submitting:
  1. Build successfully: Ensure all configurations compile
    msbuild MttVDD.sln /p:Configuration=Release /p:Platform=x64
    
  2. Run PREfast analysis: Fix all static analysis warnings
    • Build automatically runs PREfast
    • Address any new warnings your changes introduce
  3. Test on real hardware: Install and test the driver
    • Test in a VM or test system (not your primary development machine)
    • Verify basic functionality works
    • Test your specific changes
    • Check for memory leaks and crashes
  4. Test multiple configurations:
    • Different resolutions and refresh rates
    • HDR and SDR modes
    • Multiple virtual monitors
    • Different GPU adapters
See Testing Guide for detailed testing procedures.

Commit Messages

Write clear, descriptive commit messages: Good commit messages:
Add support for custom EDID profiles per monitor

Implements per-monitor EDID configuration allowing users to specify
different EDID profiles for each virtual display. Updates XML configuration
parser to handle monitor-specific EDID paths.

Fixes #123
Format:
  • First line: Brief summary (50 characters or less)
  • Blank line
  • Detailed description explaining what and why
  • Reference related issues with Fixes #123 or Relates to #456

Pull Request Process

1. Prepare Your Pull Request

Before opening a PR:
  • Code compiles without errors on x64 and ARM64
  • All PREfast warnings addressed
  • Changes tested on real hardware
  • Commit messages are clear and descriptive
  • Code follows project style guidelines
  • Documentation updated (if applicable)

2. Push to Your Fork

git add .
git commit -m "Your descriptive commit message"
git push origin feature/your-feature-name

3. Open a Pull Request

  1. Go to your fork on GitHub
  2. Click Pull Request button
  3. Select base repository: VirtualDrivers/Virtual-Display-Driver
  4. Select base branch: master (or appropriate branch)
  5. Select your feature branch
  6. Fill out the PR template:
PR Template:
## Description
[Brief description of your changes]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Performance improvement
- [ ] Documentation update
- [ ] Code refactoring

## Testing
[Describe how you tested your changes]

- [ ] Tested on x64
- [ ] Tested on ARM64  
- [ ] Tested with multiple monitors
- [ ] Tested HDR functionality

## Related Issues
Fixes #[issue number]

## Screenshots (if applicable)
[Add screenshots demonstrating the change]

## Checklist
- [ ] Code compiles without errors
- [ ] PREfast analysis passes
- [ ] Changes tested on hardware
- [ ] Documentation updated

4. Code Review

Project maintainers will review your PR:
  • Feedback: Address any requested changes
  • Discussion: Be open to suggestions and alternatives
  • Iteration: Update your PR based on feedback
  • Approval: PR will be merged once approved
Responding to feedback:
# Make requested changes
git add .
git commit -m "Address review feedback: fix XYZ"
git push origin feature/your-feature-name

Reporting Issues

Bug Reports

Use the Bug Report template: Include:
  • Windows version and build number
  • Driver version
  • GPU model and driver version
  • Steps to reproduce
  • Expected vs. actual behavior
  • Logs or error messages
  • Screenshots (if applicable)

Feature Requests

Use the Feature Request template: Include:
  • Clear description of the feature
  • Use case and motivation
  • Potential implementation approach
  • Examples from similar projects

Questions

Use the Question template for:
  • Usage questions
  • Configuration help
  • General inquiries

Community Scripts

Contribute PowerShell scripts to help users:
  1. Add your script to Community Scripts/ directory
  2. Include a README explaining what it does
  3. Add usage examples
  4. Test on multiple systems
See existing Community Scripts for examples.

Code of Conduct

Our Standards

  • Be respectful: Treat all community members with respect
  • Be constructive: Provide helpful feedback
  • Be inclusive: Welcome contributors of all backgrounds
  • Be collaborative: Work together toward common goals

Unacceptable Behavior

  • Harassment or discrimination
  • Trolling or insulting comments
  • Publishing others’ private information
  • Other unprofessional conduct

Enforcement

Project maintainers may remove, edit, or reject contributions that don’t follow these guidelines.

Support the Project

Financial Support

If you’d like to support the developers:

Spread the Word

  • Star the repository on GitHub
  • Share the project with others
  • Write blog posts or tutorials
  • Create video guides

Recognition

Contributors

All contributors are recognized in:
  • GitHub Contributors page
  • Project README acknowledgements
  • Release notes (for significant contributions)

Past Contributors

Special thanks to past contributors:
  • Bud - Former Lead Programmer
  • Roshkins - Original repository
  • Baloukj - 8-bit/10-bit support
  • Anakngtokwa - Driver source assistance
  • And many others in the README acknowledgements

License

By contributing, you agree that your contributions will be licensed under the same license as the project (see LICENSE).

Questions?

If you have questions about contributing:
  1. Check existing GitHub Discussions
  2. Read the Wiki
  3. Open a new Question issue

Next Steps

Build Requirements

Set up your development environment

Code Structure

Understand the codebase organization
Thank you for contributing to the Virtual Display Driver project!

Build docs developers (and LLMs) love