Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2255: xf86-video-glamo/703acea13: xrandr -o
1; xrandr -o 3 causes distortion (Openmoko Public Trac)
2. Openmoko Bug #2263: xf86-video-glamo/703acea13: xrandr
--output LCD --mode 240x320 incorrect screen position
(Openmoko Public Trac)
3. Re: Openmoko Bug #2263: xf86-video-glamo/703acea13: xrandr
--output LCD --mode 240x320 incorrect screen position
(Openmoko Public Trac)
4. Re: Openmoko Bug #2255: xf86-video-glamo/703acea13: xrandr -o
1; xrandr -o 3 causes distortion (Openmoko Public Trac)
5. Re: Openmoko Bug #2255: xf86-video-glamo/703acea13: xrandr -o
1; xrandr -o 3 causes distortion (Openmoko Public Trac)
6. Openmoko Bug #2264: Heavy GPRS traffic causes a Calypso crash
(Openmoko Public Trac)
--- Begin Message ---
#2255: xf86-video-glamo/703acea13: xrandr -o 1; xrandr -o 3 causes distortion
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Comment(by lindi):
What's the status of this bug? Couldn't we just have a kernel
configuration option to disable/enable this workaround if we still want to
support Xglamo but nobody has time to fix Xglamo itself.
CONFIG_WORKAROUND_BUGGY_XGLAMO, anyone?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2255#comment:11>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2263: xf86-video-glamo/703acea13: xrandr --output LCD --mode 240x320 incorrect
screen position
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
[ I hope it is appropriate to use docs.openmoko.org for Xorg driver bugs
even though openmoko inc. is not shipping it yet. ]
Steps to reproduce:
1) xrandr --output LCD --mode 240x320
Expected results:
1) X switches to 240x320
Actual results:
1) X switches to 240x320 but bottom of the screen is shown at top of the
screen. As if the hardware was doing "(y + 30) % 320" before putting the
pixel to screen. I also see odd horizontal lines which are somewhat
difficult to describe without a photo (I'll try to provide one later). Do
you have some preferred test images?
More info:
1) kernel is from andy-tracking b8b36e5ec3db71d5
2) X is from debian experimental, xserver-xorg-core 2:1.5.99.902-1
3) xf86-video-glamo is 703acea13
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2263>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2263: xf86-video-glamo/703acea13: xrandr --output LCD --mode 240x320 incorrect
screen position
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
If I try to switch back with
xrandr --output LCD --mode 480x640
the display offset is still wrong but I see no extra horizontal lines.
After this
xrandr --output LCD --mode 240x320
changes the offset to maybe only 20 pixels. Suspending and resuming seems
to zero the offset.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2263#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2255: xf86-video-glamo/703acea13: xrandr -o 1; xrandr -o 3 causes distortion
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Comment(by arhuaco):
This is out of scope for me also. If we know exactly what the workaround
is and someone wants to fix in where it should be fixed I think we could
add the .config option. Now the question is: who is going to fix
Xglamo(whatever needs to be fixed)?
I also guess we can delay this change until we actually need it. Right?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2255#comment:12>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2255: xf86-video-glamo/703acea13: xrandr -o 1; xrandr -o 3 causes distortion
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Comment(by arhuaco):
Replying to [comment:6 lindi]:
> I reverted now both 8e07543735b1b180ff45993f0e3cc82dad8142ea and
6bf861ed654ff59cdf8829e47d6b7361c40f75ba and everything seems to work
normally:
Ok. We talked on IRC about this. The current status is:
- We can not remove the workaround because people might depend on it now.
- We will make it opt-out, probably with a /sysfs entry. That could help
development.
- I'll add this task to my TODO list. If in a week or so nobody has done
it I'll do it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2255#comment:13>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2264: Heavy GPRS traffic causes a Calypso crash
----------------------------+-----------------------------------------------
Reporter: budfive | Type: defect
Status: new | Priority: normal
Milestone: | Component: GSM Modem
Version: unspecified | Severity: normal
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
----------------------------+-----------------------------------------------
I am running SHR-unstable with moko11beta on my Calypso. If I download a
large file with GPRS, I am seeing the Calypso stop responding to AT
commands, and generally go dead. The time or amount of data it takes for
the Calypso to die seems to vary (2-20 minutes usually). It also doesn't
matter what the downloaded data is. I usually download a file of zeros to
trigger the bug (http://secretsauce.net:5050/zeros). I'm attaching a
Calypso debug log collected from the headphone jack. I don't have the
documentation to interpret the log, but the stuff at the end doesn't look
good.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2264>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
