The output is not centered.
I am not sure how to achieve that because SDL just sets a "video mode"
which starts at upper left corner of the window.
It would be possible to make the mode larger but then the zoom routines
would have to take an offset.
Signed-off-by: Michal Suchanek
enabled.
Thanks
Michal
Signed-off-by: Michal Suchanek
---
hw/isa.h|1 +
hw/pckbd.c | 36 +---
qemu-options.hx |9 +
vl.c|4
4 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/hw/isa.h b/hw/isa.h
it to work.
>
Can't it print the oops on whatever is currently displayed?
It need not be a dedicated buffer as long as there is always some buffer.
But perhaps this is more complex than that.
Thanks
Michal
--
at bad idea.
Since with KMS the kernel finally knows what X is doing with the
graphics it should be able to print it. Note that it may be the only
way to see it in situations when the console dies in one way or
another.
Thanks
Michal
--
yer you can
choose from the resolutions available in the current output setup, in
kmset or whatever - drm layer you can set up the outputs, merge
multiple outputs into single cloned fbdev or separate them, ..
It's obviously nice if you can set the resolution on all of fbcons,
e kernel virtual consoles on different heads might
be nice toy but it's probably too hard to be worth trying. And there
are always applications like jfbterm which could be perhaps slightly
adapted to use one of the other devices instead of a vc.
Thanks
Michal
.
There are other drivers that support multihead already (matroxfb, any
other?) and have their own driver-specific inteface.
Designing an unified multihead fbdev extension interface would
probably take quite a bit of typing and time. It would also help to
have something working to compare to.
Thank
On 3 March 2010 06:02, Dave Airlie wrote:
> On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek wrote:
>> On 21 November 2009 05:27, Dave Airlie wrote:
>>
>>> At the moment the problem with fbset is what to do with it in the
>>> dual head case. Currently we cr
ation on each head.
For old fbset setting something visible is probably good enough.
Schemes which would make a multihead setup look like a single screen
get complicated quite easily. Perhaps an option to turn off some
outputs so that the native resolution of one output is used (ins
Sedat Dilek wrote on 2010-01-06 18:54:
> Compile-tested OK.
>
>
Thanks, commited.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A
ly signed/unsigned ints with bitfields."
Kind Regars,
- Sedat -
I just fixed that.
Actually, we could go back to bitfields and fix broken svga_fs_key_size().
Attached a patch.
Can somebody review, test-build and commit?
>From 7321aef0dfc5bb160ec8a33d1d4e686419f2ed3d Mon Sep 17
a default behaviour (assumed pipe A) for all cases except
>> the case that only
>> the plane assigned to the pipe B is active. It is enough to fix the issue
>> for me.
>
> I queued this.
>
>> Please test it.
>
> But it would great be Dean and/or Michal were t
2009/6/4 Krzysztof Helt :
> On Wed, 3 Jun 2009 11:27:17 +0200
> Michal Suchanek wrote:
>
>> Unfortunately I did not get to testing the patch yet.
>>
>> According to the description it is supposed to resolve some confusion
>> over what pipe is enabled or not.
lt behaviour (assumed pipe A) for all cases except
>> the case that only
>> the plane assigned to the pipe B is active. It is enough to fix the issue
>> for me.
>
> I queued this.
>
>> Please test it.
>
> But it would great be Dean and/or Michal were to
rent issue.
I will try to rebuild 2.6.29 with intelfb and the patch to see if that
makes a difference.
Currently efifb does give correct geometry but wrong colours for me,
the other framebuffers would also produce picture with wrong geometry
with 2.6.26.
Thanks
Michal
--
CTED]>
Michel Dänzer <[EMAIL PROTECTED]>
Kristian Høgsberg <[EMAIL PROTECTED]>
Handled-By :
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
--
Patch : http://lkml.org/lkml/2007/5/12/93
Status : patch available
Memory management
Subject: bug in i386 MTRR initialization
References : http://lkml.org/lkml/2007/5/19/93
Submitter : Andrea Righi <[EMAIL PROTECTED]>
Status : patch available
Regards,
Michal
--
&quo
d *perfectly* (performance way better than
on Windows) for quite a time (about a year I believe).
Thanks in advance for any help,
Michal Kepien
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? S
> Sorry folks, I attached the wrong file. This is the second time in a
> week. I have to be more careful. Now the correct program.
You're simply working too hard :-) Here you go:
http://kempniu.no-ip.com/files/teximage.jpg (Savage/IX 8 MB)
Best regards,
Mi
U -lglut teximage.c -o teximage
Well, I don't really know what _should_ I get, but here you go :-)
http://kempniu.no-ip.com/files/texturetest.jpg (Savage/IX 8 MB)
Oh and BTW: the compile command you've shown uses the filename teximage.c, but
you attached texturetest.c
following:
$ cd ./lib/font/Type1
$ rm -f *.o *.a
$ make && make install
Repeat these steps for the other 2 directories involved (see above).
Worked OK for me, guess those printf's are just debugging messages (are they?).
Good luck,
Michal Kepien
Or maybe DGA support is still
experimental? If so, take your time - I just wanna know whether I have anything
to work with.
Thanks in advance for any help and good luck to all of you out there!
Michal Kepien
---
SF email is sponsored by
version 2.3.2. Is anything else
worth mentioning? Dunno. If you'd like to review my whole Xorg.0.log, here it
is:
http://kempniu.no-ip.com/files/Xorg.0.log
I'd be grateful for any clues as I already saw posts about successful DRI
installations using Savage IX and I
otherwise great drivers. I am especially looking forward to
texmem branch, it should help those having only 32MB on-card memory,
right? :-)
Michal Bukovjan
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM +
Adam Duck wrote:
>>>>>>"Michal" == Michal Bukovjan <[EMAIL PROTECTED]> writes:
>>>>>>
>>>>>>
>
>Michal> Keith Whitwell wrote:
>>> Can someone out there check this quickly?
>>&g
On Tue, 16 Jul 2002, Keith Whitwell wrote:
> Can someone out there check this quickly?
>
> In radeon.h in the 2d driver, the size of the radeon mmio area is defined as
> 0x8 - however, on my r200 at least, /proc/pci shows the area as being
> 1/8th that size:
>
>Bus 1, device 0, fun
hnologies Inc Radeon QD (rev 0).
IRQ 10.
Master Capable. Latency=32. Min Gnt=8.
Prefetchable 32 bit memory at 0xd000 [0xd7ff].
I/O at 0xc000 [0xc0ff].
Non-prefetchable 32 bit memory at 0xdd00 [0xdd07].
Michal
---
Hey Ian,
Well I just got my dri working and it works reasonable well I play ut @
1280x960 and it's fairly smooth for alpha level drivers. The 2d has
always worked, works with the radeon driver. Now I have a original ati
8500 board and I really like it including the 2d. Now that that 3d is
s
As far as I understand it's something about sending commands to the AGP
card directly, not having to go through memory, improving speed. Now I
can't really ellaborat because I don't know to much about it.
On Thu, 11 Jul 2002, Mike Mestnik wrote:
> This worked for me, but my Radeon 7500 QL is ok
Hi everyone,
Thanks to the help of Stefan and others I got my r200 to work, from
Stefans lspci logs I was able to figure out why I lost my signal, it was
hardware configuration related. I had to disable Fast Writes for AGP,
simple solution took a bit of time to find, but anyone else having
probl
On Thu, 11 Jul 2002, Stefan Lange wrote:
> compiling from cvs shouldn't be a problem, I just followed the DRI
> Compilation Guide from the website and everything went fine (you might
> have to compile the kernel drm-module manually, but that's no trouble)
>
Completed the compile didn't help me
Hi Stefan, good to hear someone got it working. I'll give the
r200-0-1-branch a shot, see if I can compile it and get it running. Would
there be a problem if I had the radeon_dri modules still in the module/dri
directory (I'll try removing it)
>
> Did you take a look at /var/log/XFree86.0.log,
I guess I forgot to mention that I'm trying out the r200 dri drivers that
Keith released a couple of days ago. No if I reboot and do not change my
XF86Config not to load DRI then I get a lost signal. The only reason I'm
trying DRI now is b/c of the new r200_dri driver, do I have something
config
Hi,
I have a problem when I start X with dri and the radeon_drv module loaded
I lose my video signal I can still log onto the system remotely and get
the log from the startup, here is where is stops.
(II) RADEON(0): Using 8 MB AGP aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RAD
34 matches
Mail list logo
