10340 uts: tem should upport unicode

Review Request #1423 — Created Feb. 2, 2019 and submitted

tsoome
illumos-gate
10340
1420
292ad7c...
general
10340 uts: tem should upport unicode


  • 0
  • 0
  • 7
  • 1
  • 8
Description From Last Updated
domag02
  1. White-space nits.
  2. usr/src/uts/common/io/tem.c (Diff revision 1)
     
     

    Please, remove one blank before the = operator.

  3. usr/src/uts/common/io/tem_safe.c (Diff revision 1)
     
     
    Space followed by tab (+ in the following 7 lines).
  4. usr/src/uts/common/io/tem_safe.c (Diff revision 1)
     
     
    Space followed by tab (+ in the following 7 lines).
  5. usr/src/uts/common/io/tem_safe.c (Diff revision 1)
     
     
    Space followed by tab.
  6. usr/src/uts/common/io/tem_safe.c (Diff revision 1)
     
     
    Space followed by tab.
  7. usr/src/uts/common/sys/tem_impl.h (Diff revision 1)
     
     
    Space followed by tab.
  8. usr/src/uts/common/sys/tem_impl.h (Diff revision 1)
     
     
    Space followed by tab.
  9. 
      
tsoome
tsoome
jlevon
  1. 
      
  2. usr/src/uts/common/io/tem_safe.c (Diff revision 3)
     
     

    I'm curious if this per-byte thing is now sufficiently fast enough, rather than converting the whole string first and then doing a single call down?

    1. There is more about it. The current setup is that we have device memory mapped as linear frame buffer, then we have allocated ram for shadow frame buffer to use ram to fb copy to boost the scrolls (memory copy to fb is faster than fb to fb). And then we have glyph space allocated in tem, which is used to render the char to image and then to be copyed to fb and shadow fb. The largest font we do have is 16x32, with 32-bit depth it does make 2KB memmove from glyph buffer to fb and to shadow fb.

      What eventually should happen is that we do render on shadow fb ram, and then copy this area to fb. But to get there, we better complete the current transition, so we have "good enough" working solution, and then we can start to think how to make it better.

      Because we can achieve this optimization by presenting shadow fb to tem OR better yet, nuke all "pixel" stuff from tem, pass only chars with attributes down and let the bitmap side do all the rendering. Which is exactly what we want to happen to be able to start to build KMS support for boosting the gfx operations.

      What does make us stop here is an unknown state of sparc. And, of course, we really do want to get one step integrated first, then build up another, then another.

      About performance - yes, it seems we do get "good enough" result, and at this time, the most boost will actually come from optimizing scrolling/cls in tem - we only need to copy changes.

      If you do not mind, I'll drop this issue for now, but we will not abandon the idea:)

  3. 
      
jlevon
  1. Sure, sounds fine.

  2. 
      
domag02
  1. Ship It!
  2. 
      
tsoome
Review request changed

Status: Closed (submitted)

Loading...