Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: monitor-settings-database-online

• Packages affected: displayconfig-gtk, guidance-backends, xorg (bulletproof-x)

Summary

This specification describes a feedback mechanism to allow users to submit monitor setting customizations to a central repository for other users to obtain and share.

Release Note

It is now possible to easily share monitor customizations with other users, by uploading your settings to a central repository.

Rationale

Monitors provide EDID information to describe their capabilities. However, in some cases this information is inaccurate and needs to be overridden or is entirely unavailable and needs to be specified completely. The xserver includes quirks for many monitors, but far, far from all possible ones available. While this system works in general, it is weak in two particular use cases: Extremely new monitors released within a few months, with quirks that may not yet have made its way through the xserver release process; and extremely old monitors, that may not provide EDID information at all. The first use case is especially important for spreading Linux to the desktop consumer market, and the second is particularly critical for the developing nation market and education, that often are installing onto legacy hardware.

DisplayConfigGtk provides a useful mechanism for customizing monitors using *.inf files, however these updates are done only locally and must be repeated for each install by each person with the given hardware. It would save a lot of expended trouble and effort if these settings could be automatically uploaded to a central repository, from whence other users could automatically retrieve and use in doing their own installs.

Use Cases

• Quincy purchases a newly released monitor and hooks it up to his Ubuntu system. Unfortunately, the monitor's plug-and-play capabilities are faulty and report inaccurate EDID information, which breaks Xorg and puts Quincy into an incorrect resolution. Quincy goes to System > Administration > Screens and Graphics and clicks the screen ID, but the monitor model is not listed! Fortunately, he has the Windows CD that came with the monitor, so adds that and clicks "Add" in Screens and Graphics to import the *.inf driver file on the CD that came with the system. He then is prompted about uploading this information back to Ubuntu, and checks 'Accept'. He's happy to know that future users who purchase this model of monitor will be able to make use of the data he just loaded.

• Amit is a QA engineer at a hardware systems vendor that sells monitors to consumers. He receives several newly developed monitors from a subcontractor and in testing notes that Ubuntu lacks the data for these models. Previously, Amit would need to find his Ubuntu contact person and email the data to them, but now he can upload it directly by running DisplayConfigGtk, clicking Add, and pasting in each monitor's details. Shortly later, the information becomes available through the normal update mechanisms, allowing Amit to perform his quality checks of Ubuntu on the hardware easily.

• Jacob is deploying Edubuntu at a school system that uses a lot of donated computer equipment. He finds that by and large Edubuntu installs and "just works", but there are 8 systems with ancient monitors that Ubuntu fails on. Using Screens and Graphics on one of the systems, he experiments with some different settings, and finds some settings that make the monitor work at 800x600 resolution, although only in a low color mode. However, he decides this is good enough, and submits the customizations back to Ubuntu. Then, in configuring the other 7 systems, he's able to easily access and reuse those settings.
• Annette is a science teacher at Jacob's school system. She receives one of the systems with an ancient monitor, but is not satisfied with its color settings. In some thorough searching online, she finds an archive of the manufacturer's online specs for the system at www.archive.org, and in loading in the correct values is able to enable full color for it. Happily, she commits her updates to Ubuntu, and lets her fellow teachers know. Two of the teachers immediately use Screen and Graphics to pull down Annette's new data and reconfigure the monitor. The other five teachers don't care, and just leave the systems as is.
• Bryce is an xorg maintainer at Canonical. Periodically he reviews user-submitted monitor data updates, and identifies ones that are appropriate for general roll-out. He sees that a number of users have given thumbs up for the data submitted by Quincy, so flags those changes to be incorporated into xserver; by now this is already in upstream Xorg. He knows Amit and trusts his work, so even though few users have given feedback on his monitor changes, Bryce okay's them for incorporation into xserver, and also sends a patch to Debian and Xorg for them. He sees that there are two sets of data from Jacob and Annette for the same monitor model; Annette's change has several thumbs up, whereas Jacob's change has a mix of some up and some down, so he okay's Annette's change and marks Jacobs as superseded.
• Over the summer once school is out, Jacob reimages the classroom systems. In doing so, Ubuntu automatically applies the new xserver changes that Annette submitted and Bryce okayed. The five systems that still had been configured with low color modes are now updated with Annette's updated data. Jacob, who had never spoken to Annette, is pleasantly surprised that all 8 systems now "just work". Annette will also be pleased to not have to re-apply her fix.

Assumptions

• User has some means of bypassing the monitor issue sufficiently to access displayconfig-gtk (e.g., through bulletproof-x)
• Internet access available from the system with monitor issue

Design

The system will be comprised of five components:

1. displayconfig-gtk - The frontend interface

2. guidance-backends - The local backend (kde-guidance)

3. launchpad - The remote data submission repository

4. online data files - The remote data update files, in a plain text format

5. processor - The remote backend processor to extract data from launchpad and generate the online data files from it

The overall functionality will be implemented as the following distinct mechanisms:

1. Monitor data submission mechanism - Enabling users to submit data *to* the repository

2. Community monitor data retrieval mechanism - Enabling users to retrieve data *from* the repository

3. Monitor data quality feedback mechanism - Enabling users to rate data in the repository

4. Manual monitor customization mechanism - Enabling users to directly enter monitor data, if *.inf files are unavailable

Implementation

Monitor Data Submission Mechanism

DisplayConfigGtk includes a mechanism for loading and parsing an *.inf file. The following changes will be needed to enable an online feedback mechanism:

• On the Import screen, a checkbox is added with the text "Send to online monitors database".
• When Import is clicked, if the above checkbox is clicked, it will generate a monitor change request file, with:
  • Submitter's Launchpad ID (if available)
  • Monitor data from *.inf (monitor name, edid, rates, modelines, options...)
  • Description/notes
• A dialog is displayed with the data to send upstream for confirmation. They will have the option at this point of correcting the LP ID and entering additional notes
• Assuming the user has confirmed, the data is sent using apport-cli (or something analogous)

The data is then collected as bug reports on Launchpad.

Community Monitor Data Retrieval Mechanism

A backend tool will collate monitor data change request submissions into data files that are uploaded to a URL at ubuntu.com. This tool will need to have the following features:

• Parses launchpad bug reports
• Validates reports, ignoring any with incorrect formatting
• Tallies votes from users
  • Bug reports in state New with at least 10 votes, and 100% positive votes are moved to state Confirmed

  • Bug reports in state Confirmed with >50% negative votes are moved to state Incomplete

  • Bug reports in states New or Incomplete with at least 10 negative votes, and >80% negative, are moved to state Invalid

• Sanity-checks data and flags suspicious or erroneous data (particularly modelines that could damage monitors)
  • These are then moved to state Invalid
• Outputs monitor update data with the following info:
  • LP bug report ID number
  • Number of favorable votes
  • Number of unfavorable votes
  • Monitor data line, in MonitorsDB format
• Generates three data files for bugs that are:

  • Unsafe - Bug reports in state New or Incomplete.

  • Unapproved - Bug reports in states Confirmed or Triaged.

  • Approved - Bug reports in states In Progress or Fix Committed.

DisplayConfigGtk is then modified as follows:

• An "Update database" button is added to the "Choose screen" dialog
• When clicked, it will display a dialog titled "Update Monitor Database"
  • This dialog indicates that data will be downloaded from the internet
  • [x] "Use Approved Monitor Data"
  • [ ] "Use Unapproved Monitor Data"
  • [ ] "Use Unsafe Monitor Data"
• On clicking "Update", this will then attempt to retrieve the appropriate data file(s) and remove unchecked ones
• The files are stored in the same directory as MonitorsDB

kde-guidance is modified as follows:

• Code is added to displayconfigabstraction.py, method MonitorModelDB::init to load from the three downloaded files, if they exist

Monitor Data Quality Feedback Mechanism

When a user selects a screen which was taken from one of the downloaded data file, an option is provided for the user to later report about the success or failure of that mode.

DisplayConfigGtk is modified as follows:

• In the 'OK' button handler for the Choose Screen dialog, add code to:
  • Identify source of the data; skip the rest if it was from MonitorsDB or CustomMonitorsDB
  • Prompt the user, "We would appreciate your feedback on this monitor's data. Would you be willing to report your findings after booting with this configuration?"
  • If answered affirmatively, store a file in /var/lib/x11/report-status-monitor with the corresponding LP bug ID

BulletProofX in the xorg package is modified as follows:

• When starting, look for the existence of /var/lib/x11/report-status-monitor
• If it exists, prompt the user if they wish to report the failure with the monitor data
• If so, submit a negative vote to the LP bug ID
• Remove /var/lib/x11/report-status-monitor

In xorg, add a script to /etc/X11/Xsession.d to do the following:

• Look for the existence of /var/lib/x11/report-status-monitor
• Display a dialog to allow specifying a vote and/or comments about the success of the monitor setting
• Submit a vote to the LP bug ID
• Remove /var/lib/x11/report-status-monitor

Manual Monitor Customization Mechanism

In some cases, users won't have access to the *.inf file, perhaps because they don't have the original CD. In such cases, there needs to be a mechanism for entering in the appropriate data (the horizontal and vertical frequencies, or the modelines). (See Bug #148841)

DisplayConfigGtk should be modified as follows:

• Add a "custom screen" to the "generic" screens section
• When this is selected, the horizontal range and vertical refresh rate values should be displayed with text entry boxes
• Add code to check that the entered sync ranges are sensible; if not, disable the OK button
• Also display an "Advanced" button. This will launch a dialog that allows direct entry of a modeline.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

None

BoF agenda and discussion

None

---

CategorySpec