Ticket #1183 (new enhancement)

Opened 4 years ago

Last modified 3 years ago

add function to detect if we are running on a XO

Reported by: tomeu Owned by: erikos
Priority: High Milestone: 0.90
Component: sugar-toolkit Version: Unspecified
Severity: Minor Keywords:
Cc: sascha_silbe Distribution/OS: Unspecified
Bug Status: Assigned

Description

On Fri, 2009-08-14 at 17:28 -0400, Walter Bender wrote:
> I determine whether or not I am on an XO with:
> 
>     if os.path.exists('/sys/power/olpc-pm'): # then assume you are on an XO
> 

Shouldn't we encapsulate this method (is_xo?()) somewhere? I've seen it
spread in a couple of places so far.. 

Change History

  Changed 4 years ago by sascha_silbe

  • cc sascha_silbe added

  Changed 4 years ago by tomeu

  • priority changed from Unspecified by Maintainer to High
  • type changed from defect to enhancement
  • milestone changed from Unspecified by Release Team to 0.88

  Changed 3 years ago by tomeu

  • milestone changed from 0.88 to 0.90

  Changed 3 years ago by tomeu

  • severity changed from Unspecified to Minor
  • status_field changed from Unconfirmed to Assigned

  Changed 3 years ago by sascha_silbe

What exactly is this function supposed to be used for?

follow-up: ↓ 7   Changed 3 years ago by walter

From the activity developer POV, there are situations where you want to know if you are using the XO hardware: (1) to adjust the font sizes since there is a funny scaling factor; (2) know if the special sensor input modes are available; (3) exploit the extra OLPC keyboard and panel buttons.

in reply to: ↑ 6   Changed 3 years ago by sascha_silbe

Replying to walter:

From the activity developer POV, there are situations where you want to know if you are using the XO hardware:
(1) to adjust the font sizes since there is a funny scaling factor;

In that case the scaling factor should be read and used either directly or more appropriately via GTK style / sugar.graphics.style. I'm setting SUGAR_SCALING on non-XO hardware as well and even intend to extend it to take values other than 72 and 100.

(2) know if the special sensor input modes are available;

These should be discoverable by checking for the corresponding mixer controls. To be of any use the activity needs to be able to toggle them anyway.

(3) exploit the extra OLPC keyboard and panel buttons.

I don't see a reason to make this conditional, other than maybe ignoring keybinding errors if the X server doesn't know the corresponding keysyms - i.e. the same way we handle global hotkeys.

Note: See TracTickets for help on using tickets.