[krita] [Bug 395465] Monoprice 22HD pen pressure evdev

2018-06-18 Thread Edisto
https://bugs.kde.org/show_bug.cgi?id=395465

--- Comment #2 from Edisto  ---
I'm relatively new to using Linux as my main OS. It took me sometime to
understand the relation to an app, tablet driver, and protocol. Currently only
libinput works for Krita, while Blender/gimp only use evdev and wacom. 

I found an old post where you guys were working with evdev and monoprice,
bosto, parblo, etc.. The post looks pretty old so I'd only assume maybe
something in the kernel changing caused the problem. 

I found an easier way to switch between libinput and evdev without restarting,
which is just rename the xorg.conf and reboot the gdm. I guess that will have
to do =D. 

I know you guys are busy for the summer but I was just wondering if there was a
workaround to get the evdev to work, but apparently not :D. Thanks boud.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 395465] Monoprice 22HD pen pressure evdev

2018-06-15 Thread Edisto
https://bugs.kde.org/show_bug.cgi?id=395465

Edisto  changed:

   What|Removed |Added

   Platform|Other   |Ubuntu Packages

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 395465] New: Monoprice 22HD pen pressure evdev

2018-06-15 Thread Edisto
https://bugs.kde.org/show_bug.cgi?id=395465

Bug ID: 395465
   Summary: Monoprice 22HD pen pressure evdev
   Product: krita
   Version: 4.0.4
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: tablet support
  Assignee: krita-bugs-n...@kde.org
  Reporter: edi...@gmx.com
  Target Milestone: ---

Having issues between pen pressure in Blender/gimp and Krita at the same time.
In order to get my Blender/gimp to work I had to add a section within xorg.conf
in the etc/x11 directory:

Section "InputClass"
   Identifier "evdev tablet catchall"
   MatchIsTablet "on"
   MatchDevicePath "/dev/input/event*"
   Driver "evdev"
EndSection

Without the xorg.conf the sensitivity for Krita works fine, however now I have
to restart each time removing or adding the xorg.conf for each program. Do the 
evdev drivers currently not work in Krita 4.0 or is there some other issue?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 370152] Opening krita from taskbar on second monitor creates black screen (OpenGL)

2016-10-05 Thread Edisto via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=370152

Edisto <d.lath...@yahoo.com> changed:

   What|Removed |Added

   Platform|Windows CE  |MS Windows

-- 
You are receiving this mail because:
You are watching all bug changes.


[krita] [Bug 370152] New: Opening krita from taskbar on second monitor creates black screen (OpenGL)

2016-10-05 Thread Edisto via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=370152

Bug ID: 370152
   Summary: Opening krita from taskbar on second monitor creates
black screen (OpenGL)
   Product: krita
   Version: 3.0.1
  Platform: Windows CE
OS: Windows CE
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: OpenGL Canvas
  Assignee: krita-bugs-n...@kde.org
  Reporter: d.lath...@yahoo.com

Upon opening Krita on the second screen and creating a new file I receive a
black canvas as if OpenGL is broken. 

Reproducible: Always

Steps to Reproduce:
1. Place krita within system taskbar
2. Launch Krita from taskbar on second monitor
3. Create new document (Should be in OpenGL mode)

Actual Results:  
Black Canvas that is not drawable

Expected Results:  
White Canvas that is drawable

Operating System: Windows 10 Pro 64-bit 
Processor: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz (12 CPUs), ~3.3GHz
Memory: 32768MB RAM
Card name: AMD Radeon (TM) R9 Fury Series
Card name: AMD FirePro W8100 (FireGL V)

-- 
You are receiving this mail because:
You are watching all bug changes.


[krita] [Bug 366192] New: When using brush has a tendency to redraw on windows 10 with long freehand delay

2016-07-28 Thread Edisto via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366192

Bug ID: 366192
   Summary: When using brush has a tendency to redraw on windows
10 with long freehand delay
   Product: krita
   Version: 3.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Brush engine
  Assignee: krita-bugs-n...@kde.org
  Reporter: d.lath...@yahoo.com

Processor: 12x Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Memory: 32860MB 
Operating System: Windows 10 Pro
GPU: Radeon Fury X & Firepro w8100

Problem: When painting with brush on windows 10 my strokes at times redraw, or
don't appear until later with the freehand stroke taking forever to load. I've
used the Linux version and don't have this problem at all. 

Reproducible: Always

Steps to Reproduce:
1. Draw with any brush

Actual Results:  
Redraw what was already there or take long to appear

Expected Results:  
Seamless painting

-- 
You are receiving this mail because:
You are watching all bug changes.