MX-19 Beta 2.1 Feedback

[Jerry3904]

redshift.conf in MX-19

No we don't provide Redshift by default so there is no file on the ISO. And, as the Arch Wiki says, Redshift itself does not create it. So I turn to a web search again, this time on "linux redshift config file example" and find this handy little guy (BUT I know nothing of this, just search like a fool):

Code: Select all

; Global settings for redshift
[redshift]
; Set the day and night screen temperatures
temp-day=5700
temp-night=3500

; Disable the smooth fade between temperatures when Redshift starts and stops.
; 0 will cause an immediate change between screen temperatures.
; 1 will gradually apply the new screen temperature over a couple of seconds.
fade=1

; Solar elevation thresholds.
; By default, Redshift will use the current elevation of the sun to determine
; whether it is daytime, night or in transition (dawn/dusk). When the sun is
; above the degrees specified with elevation-high it is considered daytime and
; below elevation-low it is considered night.
;elevation-high=3
;elevation-low=-6

; Custom dawn/dusk intervals.
; Instead of using the solar elevation, the time intervals of dawn and dusk
; can be specified manually. The times must be specified as HH:MM in 24-hour
; format.
;dawn-time=6:00-7:45
;dusk-time=18:35-20:15

; Set the screen brightness. Default is 1.0.
;brightness=0.9
; It is also possible to use different settings for day and night
; since version 1.8.
;brightness-day=0.7
;brightness-night=0.4
; Set the screen gamma (for all colors, or each color channel
; individually)
gamma=0.8
;gamma=0.8:0.7:0.8
; This can also be set individually for day and night since
; version 1.10.
;gamma-day=0.8:0.7:0.8
;gamma-night=0.6

; Set the location-provider: 'geoclue2', 'manual'
; type 'redshift -l list' to see possible values.
; The location provider settings are in a different section.
location-provider=manual

; Set the adjustment-method: 'randr', 'vidmode'
; type 'redshift -m list' to see all possible values.
; 'randr' is the preferred method, 'vidmode' is an older API.
; but works in some cases when 'randr' does not.
; The adjustment method settings are in a different section.
adjustment-method=randr

; Configuration of the location-provider:
; type 'redshift -l PROVIDER:help' to see the settings.
; ex: 'redshift -l manual:help'
; Keep in mind that longitudes west of Greenwich (e.g. the Americas)
; are negative numbers.
[manual]
lat=48.1
lon=11.6

; Configuration of the adjustment-method
; type 'redshift -m METHOD:help' to see the settings.
; ex: 'redshift -m randr:help'
; In this example, randr is configured to adjust only screen 0.
; Note that the numbering starts from 0, so this is actually the first screen.
; If this option is not specified, Redshift will try to adjust _all_ screens.
[randr]
screen=0
© 2019 GitHub, Inc.

Not sure what we can do about that, but will bring up the topic with the Devs who really are techies. I just search and talk a lot...

[Stevo]

Yes, we can install an example config file with the main package if it doesn't already ship one, or a better version if the included one is lame. A normal location for one would be usr/share/doc/redshift. Looking...

Redshift already ships with /usr/share/doc/redshift/example-redshift.conf. Is that what you're talking about?

Edit: the Github one is more fancy, the included one is only

Code: Select all

; Global settings
[redshift]
temp-day=5700
temp-night=3500
transition=1
gamma=0.8:0.7:0.8
location-provider=manual
adjustment-method=vidmode

; The location provider and adjustment method settings
; are in their own sections.
[manual]
lat=55.0
lon=12.0

; In this example screen 1 is adjusted by vidmode. Note
; that the numbering starts from 0, so this is actually
; the second screen.
[vidmode]
screen=1

[Stevo]

Couldn't we ship the ISO with a fancy example config file in /etc/skel, ready to take effect if the user decides to install redshift? Then they'd just have to edit the file already in their home folder.

[Richard]

f.lux seems to play better with others.
More than Redshift.

f.lux
It's in the repo although not sure of name.
Spelled differently in places.

redshift-gtk may work better than just redshift.

[Jerry3904]

Does redshift work? I installed redshift-gtk and ran it and it just kept on chugging away--no GUI. I suspect using Xfce Color Profiles might work better.

[Gerson]

Until the MX 18 version redshift worked very well but, in the following versions; it is installed and configured without problem adding geoclue-2.0 however it does not work reducing the brightness of the screen. MX19 beta 2.1 is no exception and I have installed it but although it is correctly configured, it does nothing.

[davemx]

I have a USB remote control (I've mentioned this before) and I got close to resolving the issue of connecting it to local software in MX19ß2.1

The trouble is, when it's plugged in, depending on what else is plugged in, it may be recognised as /dev/sdc or sdd or even sde.

There are two versions of the remote control and I have both! But the program I have only recognises one at a time, so I don't need to distinguish between them. But I don't want to have to guess to decide whether to mount sdc, sdd etc.

So I added this udev rule at /etc/udev/rules.d/62-urc6440.rules

Code: Select all

KERNEL=="sd*[0-9]",SYSFS{idVendor}=="06e7",SYSFS{idProduct}=="8015", SYMLINK+="usbremote"
KERNEL=="sd*[0-9]",SYSFS{idVendor}=="06e7",SYSFS{idProduct}=="8020", SYMLINK+="usbremote"

When I plug it in, nothing appears at /dev/usbremote — and even after I moved the file to /lib/udev/rules.d/62-urc6440.rules, nothing. There should be a link to /dev/sdc1 or wherever it mounted. Any idea why it's not working. Have udev rules changed and I have to do something else? I've done the self same thing in PCLinuxOS and it works.

The idea then is that I can mount /dev/usbremote ...

I don't need to do anything in MX18 it just works, but I think that later udev (or something) has left this piece of hardware behind and it has to be done manually from now on.

OK cracked it. It's a change to udev, and the method has changed. I don't actually need a new rule in udev. A symlink has already been created, as soon as you plug it in. It's at:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1

So, to mount it, it would be somthing like sudo mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mount/point....

What's more it's exactly the same for both versions of the remote!

[WarhawkCZ]

Guys, I may have overlooked the information but can't find it. Will the beta automatically update to the final version when released? (I expect so).

[dreamer]

Some clarification:

1. Redshift works well from MXPI - nice improvement from MX-17!
2. The global conf file (which must be there with some default values) is hard to find, maybe only the developer knows where it is.
3. I copied my personal redshift.conf file from MX-17 to MX-19 home folder (to /.config/redshift/redshift.conf). It works well.

I knew I could copy my personal conf file and I'm glad it worked - I was just curious where global defaults for Redshift are stored.

If someone is interested here is what my (aggressive dimming) redshift.conf looks like. I set transition to 0 mostly for testing purposes, because I wanted to see the effect kick in.

Code: Select all

; Global settings for redshift
[redshift]
; Set the day and night screen temperatures
temp-day=4500
temp-night=3700

; Enable/Disable a smooth transition between day and night
; 0 will cause a direct change from day to night screen temperature.
; 1 will gradually increase or decrease the screen temperature.
transition=0

; Set the screen brightness. Default is 1.0.
brightness=0.8
; It is also possible to use different settings for day and night
; since version 1.8.
;brightness-day=0.7
;brightness-night=0.4
; Set the screen gamma (for all colors, or each color channel
; individually)
gamma=1.0
;gamma=0.8:0.7:0.8
; This can also be set individually for day and night since
; version 1.10.
;gamma-day=0.8:0.7:0.8
;gamma-night=0.6

; Set the location-provider: 'geoclue', 'geoclue2', 'manual'
; type 'redshift -l list' to see possible values.
; The location provider settings are in a different section.
location-provider=geoclue2

; Set the adjustment-method: 'randr', 'vidmode'
; type 'redshift -m list' to see all possible values.
; 'randr' is the preferred method, 'vidmode' is an older API.
; but works in some cases when 'randr' does not.
; The adjustment method settings are in a different section.
adjustment-method=randr

; Configuration of the location-provider:
; type 'redshift -l PROVIDER:help' to see the settings.
; ex: 'redshift -l manual:help'
; Keep in mind that longitudes west of Greenwich (e.g. the Americas)
; are negative numbers.
[manual]
;lat=48.1
;lon=11.6

; Configuration of the adjustment-method
; type 'redshift -m METHOD:help' to see the settings.
; ex: 'redshift -m randr:help'
; In this example, randr is configured to adjust screen 1.
; Note that the numbering starts from 0, so this is actually the
; second screen. If this option is not specified, Redshift will try
; to adjust _all_ screens.
[randr]
;screen=1

Couldn't we ship the ISO with a fancy example config file in /etc/skel, ready to take effect if the user decides to install redshift? Then they'd just have to edit the file already in their home folder.

That's a good idea. It's easier to edit a file that is already present than to create a new. And based on my experience from MX-17, the example files given by the developer didn't work on my system without modifications.

[m_pav]

1+

I agree, we should just stick to 24 hour format by default. It's not like we're holding users hostage with it, they can select what time format they want anyway. There are a handful of countries on that 12hr list which use both formats.

Perhaps, I may translate this for other reading this: We shall stick to the default time representation of those countries locale like en_AU and en_NZ, which have both 12h and 24h, and use Debian's default time format, which is 24h-clock for en_AU and en_NZ and for other like en_US, en_CA, el_GR ... the default 12h would also be used. The advantage of sticking to the default, would be for any clock a user might choose the default would be in place according to the locale LC_TIME default.
Otherwise we would have to many different time display formats (e.g. at the Login screen, at the panel (orage-clock, xfce-datetime, Conky clock).

No for the 24-hour clock in NZ, Au can have it but not here. I think of the thousands of people I have served, only a handful use the 24 hour clock. We do not like calling 5:20PM 17:20, it just doesn't make any sense around here. Schools still teach the 12 hour clock, so that way it must stay.