Public bug reported:

According to the fbterm manpage the sequence "ESC  [  3 ; n ; r ; g ; b
}" should change the colour "n" to the specified values. However, this
only works when changing the first colour. When changing another colour
a switch to another tty and back is needed to apply the changes.

Steps to reproduce:

*) start fbterm
*) print all the colours (e.g. using 'for i in {0..255}; do echo -ne "\E[2;$i} 
"; done; tput sgr0; echo')
*) change a colour (e.g. using 'echo -e "\E[3;16;0;255;0"')
*) verify that the change has been applied by e.g. printing all the colours 
again
*) change another colour (e.g. 'echo -e "\E[3;17;0;255;0"')
At this point the colour map doesn't change anymore, no matter how many colours 
I change. Only switching to another tty and back again applies my changes.

The bug: in src/screen_render.cpp, line 39 (in function
"Screen::setPalette"): When setPalette is called it checks whether the
pointer to the palette has changed in this line. However, the pointer is
only changed the first time a colour is changed by "FbShell::request" in
src/fbshell.cpp (the function starts in line 510). The changes are
written to the palette as they should (but "setPalette" assumes that
nothing has changed since the pointer doesn't change).

Commenting "if (mPalette == palette) return;" out in line 39 in
src/screen_render.cpp seems to work for me.

I'd *guess* it would be safe to remove the check from "setPalette" since
it seems to me that it isn't called often anyway?

All the information as requested by the Ubuntu bug reporting guidelines:

1) "lsb_release -rd"
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
2) "apt-cache policy fbterm"
fbterm:
  Installed: 1.7-2
  Candidate: 1.7-2
  Version table:
 *** 1.7-2 0
        500 http://ubuntu.lagis.at/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status
3) what I'd expect to happen
changing multiple colours works as described in the man page
4) what actually happens
only one colour could be changed as described in the man page (and further 
colours needed switching to another tty)

(edit: formatting)

** Affects: fbterm (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  According to the fbterm manpage the sequence "ESC  [  3 ; n ; r ; g ; b
  }" should change the colour "n" to the specified values. However, this
  only works when changing the first colour. When changing another colour
  a switch to another tty and back is needed to apply the changes.
  
  Steps to reproduce:
  
  *) start fbterm
  *) print all the colours (e.g. using 'for i in {0..255}; do echo -ne 
"\E[2;$i} "; done; tput sgr0; echo')
  *) change a colour (e.g. using 'echo -e "\E[3;16;0;255;0"')
  *) verify that the change has been applied by e.g. printing all the colours 
again
  *) change another colour (e.g. 'echo -e "\E[3;17;0;255;0"')
  At this point the colour map doesn't change anymore, no matter how many 
colours I change. Only switching to another tty and back again applies my 
changes.
  
- Bug in the code: in src/screen_render.cpp, line 39 (in function
+ The bug: in src/screen_render.cpp, line 39 (in function
  "Screen::setPalette"): When setPalette is called it checks whether the
  pointer to the palette has changed in this line. However, the pointer is
  only changed the first time a colour is changed by "FbShell::request" in
  src/fbshell.cpp (the function starts in line 510). The changes are
  written to the palette as they should (but "setPalette" assumes that
  nothing has changed since the pointer doesn't change).
  
  Commenting "if (mPalette == palette) return;" out in line 39 in
  src/screen_render.cpp seems to work for me.
  
  I'd *guess* it would be safe to remove the check from "setPalette" since
  it seems to me that it isn't called often anyway?
  
- 
  All the information as requested by the Ubuntu bug reporting guidelines:
  
  1)
  "lsb_release -rd"
  Description:  Ubuntu 14.04.5 LTS
  Release:      14.04
  2)
  "apt-cache policy fbterm"
  fbterm:
-   Installed: 1.7-2
-   Candidate: 1.7-2
-   Version table:
-  *** 1.7-2 0
-         500 http://ubuntu.lagis.at/ubuntu/ trusty/universe amd64 Packages
-         100 /var/lib/dpkg/status
+   Installed: 1.7-2
+   Candidate: 1.7-2
+   Version table:
+  *** 1.7-2 0
+         500 http://ubuntu.lagis.at/ubuntu/ trusty/universe amd64 Packages
+         100 /var/lib/dpkg/status
  3)
  changing multiple colours works as described in the man page
  4)
  only one colour could be changed as described in the man page (and further 
colours needed switching to another tty)

** Description changed:

  According to the fbterm manpage the sequence "ESC  [  3 ; n ; r ; g ; b
  }" should change the colour "n" to the specified values. However, this
  only works when changing the first colour. When changing another colour
  a switch to another tty and back is needed to apply the changes.
  
  Steps to reproduce:
  
  *) start fbterm
  *) print all the colours (e.g. using 'for i in {0..255}; do echo -ne 
"\E[2;$i} "; done; tput sgr0; echo')
  *) change a colour (e.g. using 'echo -e "\E[3;16;0;255;0"')
  *) verify that the change has been applied by e.g. printing all the colours 
again
  *) change another colour (e.g. 'echo -e "\E[3;17;0;255;0"')
  At this point the colour map doesn't change anymore, no matter how many 
colours I change. Only switching to another tty and back again applies my 
changes.
  
  The bug: in src/screen_render.cpp, line 39 (in function
  "Screen::setPalette"): When setPalette is called it checks whether the
  pointer to the palette has changed in this line. However, the pointer is
  only changed the first time a colour is changed by "FbShell::request" in
  src/fbshell.cpp (the function starts in line 510). The changes are
  written to the palette as they should (but "setPalette" assumes that
  nothing has changed since the pointer doesn't change).
  
  Commenting "if (mPalette == palette) return;" out in line 39 in
  src/screen_render.cpp seems to work for me.
  
  I'd *guess* it would be safe to remove the check from "setPalette" since
  it seems to me that it isn't called often anyway?
  
  All the information as requested by the Ubuntu bug reporting guidelines:
  
- 1)
- "lsb_release -rd"
+ 1) "lsb_release -rd"
  Description:  Ubuntu 14.04.5 LTS
  Release:      14.04
- 2)
- "apt-cache policy fbterm"
+ 2) "apt-cache policy fbterm"
  fbterm:
    Installed: 1.7-2
    Candidate: 1.7-2
    Version table:
   *** 1.7-2 0
          500 http://ubuntu.lagis.at/ubuntu/ trusty/universe amd64 Packages
          100 /var/lib/dpkg/status
- 3)
+ 3) what I'd expect to happen
  changing multiple colours works as described in the man page
- 4)
+ 4) what actually happens
  only one colour could be changed as described in the man page (and further 
colours needed switching to another tty)
+ 
+ (edit: formatting)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1614241

Title:
  changing colours in the palette only works with workarounds

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fbterm/+bug/1614241/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to